Aller au contenu | Aller au menu | Aller à la recherche

Another Home Page Blog

lundi, septembre 2 2013

obtenir facilement les propriétés d'un fichier avec stat

Généralement, quand on cherche à obtenir les propriétés d'un fichier, on utilise la commande ls, avec l'argument -l, ce qui donne un résultat proche de ceci :

nils@orgrimmar:~$ ls -l /dev/null 
crw-rw-rw- 1 root root 1, 3 août  4 11:21 /dev/null

C'est bien gentil, mais si on ne souhaite avoir comme information que le propriétaire d'un fichier, ça fait beaucoup de choses à filtrer. Filtrer la sortie de ls avec awk n'est pas le truc le plus méchant, mais je trouve que c'est comme utiliser un fusil à pompe pour se débarrasser d'une mouche. On est dans le monde UNIX, là où il y a des programmes qui ne font qu'une seule tâche, mais qui la font bien.

Et l'outil qui fait cela se nomme tout simplement stat, et est disponible sur de nombreux systèmes. Sous RHEL/CentOS, il est inclus dans le paquet coreutils, et il est installé avec le système de base dans NetBSD. Là où c'est par contre un peu moins drôle, c'est que l'implémentation Linux diffère de l'implémentation BSD.

Exemple, sous Linux :

nils@orgrimmar:~$ stat -c %U /dev/null 
root

Et ensuite sous NetBSD :

nils@dev:~$ stat -c %U /dev/null 
stat: unknown option -- c
usage: stat [-FlLnqrsx] [-f format] [-t timefmt] [file ...]

Allez, on recommence avec les bonnes options :

nils@dev:~$ stat -f %Su /dev/null 
root

Ici, j'ai cherché à afficher le nom de l'utilisateur propriétaire du fichier, mais d'autres propriétés sont disponibles, comme le nom du groupe, les UID et GID propriétaires, les droits, la taille, les dates de création et de modification, le nom du fichier... D'ailleurs, lancé sans autre argument que le nom du fichier, stat propose bon nombre d'informations.

lundi, août 26 2013

freeshell : votre accès terminal UNIX sur internet

Je me suis dit que ça serait sympa de vous faire découvrir l'association SDF (pour Super Dimension Fortress) et son projet freeshell : un accès en mode terminal sur une machine UNIX (NetBSD pour être exact). Cet accès, dans certaines conditions, est gratuit. C'est assez chouette, ça existe depuis très longtemps et permet d'apprendre les rudiments d'UNIX sans forcément installer en physique ou en virtuel ce type d'environnement. L'association fait cela à but éducatif et culturel, et est reconnue "non-profit" (oui, c'est une association américaine).

Pour accéder à freeshell, et créer un compte, il suffit de se munir d'un client SSH et de se connecter de la façon suivante :

ssh new@sdf.org

il existe d'autres moyens, qui reposent généralement sur SSH ou telnet, sur la page d'inscription au service.

J'ai indiqué plus haut que sous certaines conditions, ce service est gratuit : il y a en fait différent niveaux de services, selon ce que vous êtes prêts à payer. Une fois le compte et l'accès créé, vous disposez de certains outils, comme :

  • mutt, pop3, imap, icq, twitter, bsflite (aim), irc (sur le réseau SDF) ;
  • games, mud, lynx, gopher, TOPS-20 ;
  • hébergement HTTP statique de type http://yourlogin.sdf.org (d'autres domaines sont possibles) ;
  • traceroute, ping, whois, dig et d'autres.

mais tout ça est dans un shell limité. Si vous consentez à payer une petite somme (historiquement 1 Dollar US), un accès shell "classique" (comprendre : bash, ksh, tcsh, rc ou zsh) vous est alors ouvert, avec bien plus de possibilités, comme le webmail, FTP, SFTP (en entrée, pas en sortie), ou un accès à plus d'outils. Pourquoi le shell limité et pourquoi la somme ? Pour éviter le spam d'une part, et d'autre part car le traitement peut se faire par courrier papier, il suffit d'envoyer un billet de 1 Dollar (ou de 5 Euros) à l'adresse indiquée dans la page d'explication.

Encore plus d'outils et de possibilités sont offertes à qui est prêt à mettre un peu plus la main au portefeuille, et certains services sont facturés au mois, comme par exemple un accès VPN. Le tout est hébergé aux USA, et il existe aussi une version européenne, hébergée en Allemagne : SDFEU. Rien que pour l'accès shell, traceroute, dig, whois et autres lynx, c'est assez pratique je trouve, d'avoir un point "de sortie" ailleurs que dans son pays d'origine. Cela permet par exemple de tester des filtrages (géolocalisation ?). C'est aussi, à mon sens, un moyen de disposer d'un hébergement web (statique) peu coûteux et à taille plus humaine, et à finalité moins commerciale.

lundi, août 19 2013

dépôt de paquets pkgsrc en mode rapide

Avec pkgsrc, on peut facilement créer des paquets binaires avant de les installer. Généralement, un simple :

nils@machine:/usr/pkgsrc/category/software$ make package

suffit pour créer un paquet. On peut l'installer avec la cible "install" en plus, mais on peut aussi faire ceci :

rm -f /usr/pkgsrc/packages/All/pkg_summary*
for i in $(ls /usr/pkgsrc/packages/All/*.tgz | sort); do pkg_info -X $i >> /usr/pkgsrc/packages/All/pkg_summary; done
bzip2 /usr/pkgsrc/packages/All/pkg_summary

Ensuite, ajouter dans sa configuration pkgin le dépôt suivant : file:///usr/pkgsrc/packages/All. Un pkgin in nomdupackage plus tard, et tout est installé. C'est d'autant plus sympathique pour les mises à jour. Ainsi, j'ai ajouté les commandes précédentes dans un script shell que j'appelle après compilation du paquet. Je peux aussi copier les paquets avec le fichier pkg_summary.bz2 à un autre endroit pour que d'autres machines en profitent. Mais tout ceci est manuel et ne saurait remplacer une infrastructure de bulk build.

mardi, août 13 2013

10 ans de dotclear

Je me prend au jeu de fêter les 10 ans du moteur de blog Dotclear, comme annoncé sur Twitter, dont je reprend le texte ici, pour archive :

Pour les 10 ans de #Dotclear le 13/08/13, publiez sur votre blog le 13 août votre texte : "Dotclear et moi, tout une histoire" #dotclear10

Alors voilà, Dotclear ça fait presque 8 ans que je m'en sers (voir mon premier billet, rien d'original, j'ai même changé le nom du blog depuis). Et franchement, même si j'y ai pensé, je n'ai pas prévu de changer de crèmerie. Pourquoi ? Parce que :

  • ça fonctionne ;
  • ça fournit tout ce dont j'ai besoin, ou presque ;
  • c'est du logiciel libre ;
  • c'est français (j'avoue, je suis assez chauvin sur ce coup) ;
  • ça n'a pas l'air d'une usine à gaz ;
  • et c'est encore développé.

J'ai réussi à transvaser ce blog d'un hébergement Free à 1and1, puis à mon serveur dédié, sous différents OS, différentes versions d'Apache, de PHP, de MySQL, au gré de l'évolution de mes compétences techniques. Dotclear a été le premier témoin de ces évolutions, quelque part le premier outil aussi.

Alors, joyeux anniversaire, Dotclear ! Puisse-tu te développer encore plus et encore mieux pour les 10 prochaines années !

lundi, août 12 2013

sudoers.d

J'ai mis du temps à m'en rendre compte : la plupart des OS récents disposant de sudo ont en plus de leur fichier sudoers un répertoire nommé sudoers.d. A quoi sert ce répertoire ? Tout simplement à inclure des fichiers de configuration sudo, en utilisant la même syntaxe que le fichier sudoers. Comment cela est-il possible ? Grâce à la capacité de sudo à inclure des fichiers de configuration, comme en témoigne cet extrait (pris sous NetBSD), généralement à la fin du fichier sudoers :

## Read drop-in files from /usr/pkg/etc/sudoers.d
## (the '#' here does not indicate a comment)
#includedir /usr/pkg/etc/sudoers.d

Maintenant, au lieu d'ajouter de la configuration dans sudoers, il suffit de créer un fichier, par exemple sudoers.d/toto contenant notre configuration personnelle.

Et pour la compatibilité ? La plus vieille version de sudo que j'ai testée avec succès est la 1.7.2p1, sur une CentOS 5. J'ai aussi fait un test sur une RHEL 4.5 (disposant de sudo 1.6.7p5), mais celui-ci n'était pas concluant.

- page 1 de 33