monsieurw a écrit 193 commentaires

Bah, ça serait la syntaxe en PHP. Rien n'empêche d'utiliser PHP en tant que shell, n'est-ce pas ?

Une remarque : la syntaxe $(<cmd>) est un bash-isme (si vous me permettez l'expression). Ca fonctionne aussi avec "zsh", mais pas avec "sh", "csh", "tcsh"...
Si le script doit être portable, c'est important à savoir.

Note : je préfère aussi la syntaxe $(<cmd>), qui permet de facilement imbriquer ce type d'appel, mais il faut bien indiquer que c'est un script bash (avec #! /bin/bash au début de chaque script)

Certes

J'ai un modem externe qui marche, et ajouter une carte PCI avec un port série supplémentaire est effectivement une solution à envisager. Cependant, mon idée était d'avoir un boîtier compact qui supporte aussi les connexions RTC sans avoir de périphérique en plus (moins de câbles, une seule alimentation...).

Merci

Bonjour

Ça n'est pas possible avec le démon syslog de base.

Par contre, avec une version plus évoluée comme "syslog-ng", ça devient possible (utilisation de modèles -templates-).
http://www.balabit.com/products/syslog_ng/reference-2.0/sysl(...)

1/ voir ce qui est dit dans les logs générés par cups

2/ Ici, "/dev/cdrom" est un lien symbolique vers "/dev/hdd" (je suppose). Les droits d'un lien symbolique (rwxrwxrwx) ne signifient rien ; ce sont les droits du fichier sur lequel ce lien pointe qui doivent être pris en compte.
Donc a priori, "/dev/hdd" appartient à l'utilisateur "utilisateur" et au groupe "cdrom", et seuls eux peuvent accéder en lecture/écriture à ce périphérique : il faut vérifier que l'utilisateur qui lance l'application de lecture de CD audio appartienne au groupe "cdrom", par exemple.

Conclusion/ Toute mise à jour est susceptible de provoquer des dysfonctionnements, ce n'est pas spécifique aux distributions Linux. Ça arrive également avec d'autres OS (exemples : passage de MacOS X.1 vers X.3 -> j'ai finalement du réinstaller complètement le système pour que tout soit OK ; le passage au SP2 de winXP a parfois été douloureux -pas testé personnellement-)

Si on peut booter depuis une carte CF et surtout par PXE, ça me convient parfaitement.


Attention, si le service de kd85 est irréprochable, les prix indiqués sont hors-taxe (et la TVA belge est de 21%).

Ah oui, c'est juste.

Merci pour vos infos.

Une dernière question : quel est le boitier fourni avec la carte (réf board+case 10480151 sur le site kd85) ? Celui non percé ( http://soekris.kd85.com/images/tn/DSC03718.JPG.html ) ?


--
Unk

Merci pour l'info, effectivement, on arrive à une centaine d'euros de moins avec une carte WRAP, mais elle est aussi un peu moins complète (pas de port PCI et un seul port série, par exemple).

L'avantage par rapport à un routeur bon marché est que l'on peut faire ce que l'on souhaite de son système,...


... Les avantages par rapport à un PC sont multiples: le prix, la taille, la consommation ainsi que la fiabilité.


Tout à fait, c'est pour ces raisons que je cherche une solution de ce type...

--
Unk

Non, il disait
Pfff, et puis y'en a marre que toujours on mette en avant l'unique qualité graphique d'un jeu, merde, ...

(-> une virgule a été oubliée) et non que les jeux de Sid Meier étaient de la merde, me semble-t-il...

Il est possible d'utiliser les variables d'environnements suivantes avant de lancer "psql" (exemple en bash) :

####
PGUSER=postgres
PGHOST=localhost
PGPORT=5432
PGPASSWORD=motdepasse
PGDATABASE=template1

export PGUSER PGHOST PGPORT PGPASSWORD PGDATABASE
####

Pratique pour l'écriture de scripts.

> mais je pense qu'une boite qui a une certaine éthique aurait du refuser de développer ca !

Mouais, je ne suis pas d'accord : une entreprise n'a pas "d'éthique" ni de "morale". C'est une structure destinée à gagner de l'argent. Point. Alors bien sûr, est-ce qu'une entreprise ne devrait pas faire passer ses profits après le bien-être de ses employés, le respect de l'environnement, la "moralité" de son activité, ... ? Peut-être, mais qu'on le veuille ou non, ce n'est pas comme ça que ça se passe dans la vraie vie...

Pour le coup, si ça n'avait pas été eux qui avaient développé ce truc, ça aurait été un des leurs concurrents, surtout que "l'astuce" utilisée ne semble pas extrêmement compliquée (cf post ci-dessus).

Bref...
--
Unk

Oui, mais apparamment il n'est pas possible d'avoir un serveur local (peut être avec la version complète ?)

Oui, par exemple. Il est même possible de ne pas forcément utiliser le même serveur, en utilisant les enregistrements SRV au niveau du DNS. Ça marche un peu comme l'enregistrement MX ; cf la RFC 2782 ( http://www.ietf.org/rfc/rfc2782.txt(...) )
J'avais lu quelque part que la plupart des clients Jabber recherchaient l'enregistrement correspondant à Jabber/XMPP par ce biais.

A propos de jabberd et des enregistrements SRV (cf paragraphe 5.7) : http://jabberd.jabberstudio.org/2/docs/section05.html#5_7(...)

Merci pour le lien ! Je pense que je vais me décider pour celui-là.

Merci, c'est intéressant.
Je vais regarder plus en détail tout ça.

A propos du baladeur de Samsung, il est bien présent sur le site en ".com"
http://product.samsung.com/cgi-bin/nabc/product/b2c_product_subtype(...)

J'avais écrit un début de doc pour ça, qu'on peut encore trouver là (si le serveur tourne) :

http://wop-sys.net/article24#tx5(...)

Attention, la page est assez lourde à charger (y a plein d'images de l'installation d'une Mandrake).

Ça a été fait pour une Mandrake 9.1 mais je l'ai réutilisé il y a 3 semaines pour une Mandrake 10.1 avec succès.

Il faut supprimer les sources auxquelles veulent accéder les PCs (avec "urpmi.removemedia"), puis ajouter une nouvelle source (avec "urpmi.addmedia")

Pour la distrib :

urpmi.addmedia --distrib http://serveur.web/distrib/mandrake/9.1/(...)

Pour les mises à jour :

urpmi.addmedia --update updates \
http://serveur.web/distrib/mandrake/updates/9.1/RPMS/(...) \
with ../base/hdlist.cz

Il faut bien respecter l'arborescence des paquets de la distribution et des sites d'updates.

Est-ce que l'indexation des répertoires est faite ? Un truc du genre :

Options Indexes

Ah oui, tiens, j'avais oublié ça... Ça reste peut-être un peu encombrant, mais effectivement si j'en trouve un qui marche pas cher, j'essaierais... Je pourrais trouver ça à la braderie de Lille... Bah, on verra...
Merci

Ah, pour l'édition de texte, je viens d'essayer avec "pico", ça marche nettement mieux. Et sous bash, la completion marche à peu près avec [tab] (le tout est de ne pas se tromper de touche :-/ ) Cela dit, la frappe reste laborieuse, l'organisation du clavier étant très différente d'un azerty/qwerty.
Bref...

Pour un système en Ramdisk et qui doit garder une taille raisonnable, il est préférable d'utiliser Busybox (et Tinylogin) et de le configurer pour qu'il gère directement les fichiers passwd et shadow :
cf Login/Password Management Utilities-->
[*] Use internal password and group functions (option "CONFIG_USE_BB_PWD_GRP")

J'avais réussi à bricoler un système ramdisk qui tournait sur un 486 avec 8 Mo de RAM (le ramdisk ne faisait que 3 Mo et il n'y avait que Busybox statiquement lié donc c'était un peu limité, mais bon, ça marchait). Si ça peut aider, quelques infos complémentaires à ce sujet ici :
http://wop-sys.org/sDistrib/(...)

Si c'est la Glic qui est utilisée, ça doit être un problème lié aux bibliothèques NSS (/lib/libnss* et /etc/nsswitch.conf). Même si avec un "ldd" les liens à es bibliothèques n'apparaisent pas, il fut quand même les utiliser.

Bon, à table...

Je ne sais pas comment fonctionne l'interface drakperm avec une Mandrake. Cependant, en ce qui concerne l'exécution de scripts avec grsec, on peut utiliser l'interface /proc : cf. /proc/sys/kernel/grsecurity
Là, si le noyau est compilé pour ça, on trouve 3 "variables" :
- tpe : active/désactive la gestion des chemins sûrs(*) d'exécution par le noyau (echo 1 > tpe pour activer)
- tpe_gid : numéro du GID pour lequel la restriction d'exécution s'applique
- tpe_restrict_all : tous les utilisateurs du système voient leur droit d'exécution réduit : ils ne peuvent exécuter que les programmes dans des chemins sûrs(*) et dans les répertoires qui leur appartiennent et où eux seuls ont le droit d'écriture.

Si on veut limiter les droits d'exécution des utilisateurs afin qu'ils puissent quand même lancer des scripts depuis leurs répertoires, il faut activer tpe_restrict_all mais ces mêmes utilisateurs ne doivent pas appartenir au groupe tpe_gid.

(*) les chemins sûrs d'exécution (Trusted Path Execution) sont définis de la manière suivante :
- les répertoires appartiennent au root (uid/gid = 0)
- les droits de ces répertoires sont 0755 (c'est à dire que personne à part le root ne peut écrire dedans)

Note, je ne sais pas si ces droits d'exécution peuvent aussi se gérer avec les ACL de GRSecurity, donc j'ai ptet répondu à côté de la plaque ?

Certes, c'est étonnant que des administrateurs Unix n'aient pas connaissance de ce problème, mais je n'ai pas trouvé de solution pratique pour ce problème de NFS.
Surtout, il faudrait rigoureusement interdire le branchement de machines non
autorisées sur le réseau et n'autoriser l'accès root qu'aux administrateurs (et là, les utilisateurs vont râler parce qu'ils ne peuvent plus faire ce qu'ils veulent avec "leur" machine).
Une autre idée, c'est de n'avoir qu'un fichier chiffré dans son répertoire $HOME qui est monté en loop par l'utilisateur après son login. La clef de chiffrement doit être sur une disquette/carte magnétique/clef USB. Mais ce n'est pas très pratique et ça peut poser des problèmes de performance.
On peut aussi envisager de ne plus utiliser NFS, mais Samba, par exemple. Il me semble que ce problème peut aussi être résolu avec NFSv4 ( http://www.nfsv4.org(...) et http://www.ietf.org/rfc/rfc3530.txt(...) ), mais c'est encore un peu expérimental.

Oui, bien sûr, une fois root sur sa machine, on n'a pas accès aux partages NFS grâce à "no_root_squash", mais le problème est qu'on peut créer un utilisateur avec n'importe quel UID, et il est facile de connaître les UIDs des autres utilisateurs. On crée donc un utilisateur ayant l'UID d'un gars, puis un simple "su - legars" permet d'obtenir son identité et d'accéder à ses données partagées par NFS.

De toutes façons, je ne pense pas que ça soit avec Solaris que Sun gagne le plus d'argent ; c'est plutôt sur la vente de matériels et le service (me trompe-je ?).

À l'heure actuelle, Sun semble chercher à développer un processeur massivement multi-core et multi-thread (Niagara : 8 cores et 4 threads par core, un peu comme le Cell d'IBM). L'UltraSparc V pourrait ne jamais sortir et l'équipe travaillant dessus se pencherait sur le "Rock", un processeur 30x plus rapide qu'un UltraSparc III à 1,2 Ghz (à moins qu'elle n'ait été virée http://www.aceshardware.com/read_news.jsp?id=80000468(...) :-/ ).

Voir ces articles parus sur Ace's hardware :
Niagara : A Torrent of Threads (avril 2004)
http://www.aceshardware.com/read.jsp?id=65000292(...)

TLP (Thread Level Parallelism) and the Return of KISS (janvier 2004)
http://www.aceshardware.com/read.jsp?id=60000312(...)

Oui, Busybox, TinyLogin et la uClibc, ça permet de gagner pas mal de place et en même temps d'utiliser un grand nombre d'applications ;
Voir par exemple : http://www.uclibc.org/dists/uwoody/(...)

De mon côté, j'ai déjà eu besoin de compiler PostgreSQL, ulogd, Prelude-IDS, la SDL avec la uClibc sans problèmes majeurs. Note : j'étais également parti des scripts de compilation des paquets d'une Slackware.