Catégorie : système

Linux vsftp : mémo ajout d'un utilisateur

Voilà, je perds toujours un temps fou à rechercher comment ajouter un utilisateur pour qu’il se connecte sur le serveur ftp.

Si vous n’y arrivez pas, lisez le fichier de configuration :
/etc/vsftpd.conf
Dedans il y aura beaucoup d’informations utiles.

Voilà le résumé pour ajouter un utilisateur sur le serveur vsftp :

  1. Créer l’utilisateur. Par exemple :
    noeunoeu
  2. Changer son mot de passe :
    passwd noeunoeu
  3. L’ajouter à la fin des fichiers suivants :
    • /etc/vsftpd/chroot_list
    • /etc/vsftpd/user_list

Et voilà tout devrait fonctionner !

Linux : mount permanent avec mot de passe (mémo simple)

mount donne la possibilité de faire croire qu’un répertoire de Linux existe bel et bien alors que ce n’est qu’un lien vers un autre répertoire.

Si vous voulez faire :

  • un montage qui reste, même après redémarrage de l’ordinateur ;
  • un lien vers un répertoire partagé Windows ;
  • préciser dès le début le nom d’utilisateur et le mot de passe Windows.

Voici la solution (je mets plusieurs couleurs pour bien différencier les paramètres) :
mount -t smbfs //192.168.0.85/www /root/test -o auto,username=macaille,password=bienrotie
Traduction simplifiée de l’ordre qui suit : « lorsque quelqu’un voudra accéder au répertoire /root/test, c’est en réalité le répertoire partagé www de l’ordinateur 192.168.0.85. Si on demande un utilisateur/mot de passe c’est macaille/bienrotie (quelle subtilité !) (options username/password)). Enfin, s’il redémarre, refaire automatiquement le montage : c’est l’option auto« .

Linux : Cron et cronjob

Pour éditer la table cron de l’utilisateur en cours avec vi.

crontab -e

Ensuite pour un déclenchement chaque jour à minuit d’une tâche :

# Declenchement du script creation_zip chaque jour a minuit
0 0 * * * /xx/xx/nomduscript [params] > /dev/null 2>&1

Vous vous demandez peut-être ce que signifie la fin des paramètres que vous voyez juste au dessus :

/dev/null 2>&1

Cela signifie rediriger la sortie d’erreur (2) vers la sortie normale (1) : 2>&1 et rediriger la totale résultant vers la poubelle (« /dev/null« ).

Linux : faire l'ISO d'un CD

  1. Il faut insérer le CD dans le lecteur ;
  2. Vérifier avec mount qu’il n’a pas été monté automatiquement, sinon il faut le démonter
    (umount /dev/cdrom) ;
  3. Ensuite se mettre dans une partition qui a au moins l’espace requis de libre
    (vérifier avec df -kh) ;
  4. Ensuite, taper l’ordre :
    dd if=/dev/cdrom of=/toto/cd.iso ;
  5. S’il faut le copier sur un site distant :
    scp /toto/cd.iso 192.xx.xx.xx:/sources .

Zeemoz : berkeleydb : linké avec la librairie !

J’ai trouvé comment linker les exemples de berkeley DB avec la librairie :
Lors de la compilation, l’utilitaire de lien (ld) va chercher les toutes dernières librairies qu’il connait et les lie à l’executable. Seulement, quand il ne connait pas les librairies, il faut les ajouter.
L’opération est simple : il faut lire le fichier
/etc/ld.so.conf
Sur une distro Debian, il ne contient que cette ligne : include /etc/ld.so.conf.d/*.conf
C’est donc dans le répertoire /etc/ld.so.conf.d/ qu’il nous faut créer un fichier avec un nom explicite, qui spécifie où le linker doit aussi aller chercher les librairies.
Dans mon cas j’ai crée un fichier nommé /etc/ld.so.conf.d/db.4.5.conf dans lequel j’ai mis :
# creation olivier pons 2 mai 2007
/home/sources/db-4.5.20/build_unix/.libs
Ensuite, il suffit juste de dire au linker de recharger son cache :
ldconfig
Pour plus d’infos : man ldconfig !

Linux : un serveur Knock (knockd). Mais c'est quoi ?

En résumé, il s’agit d’un système dit des « portes dérobées ». Le knockd scrute en permanence les paquets entrants et vérifie si certains d’entre eux répondent à une séquence prédéfinie, et si oui, il exécute une action. On peut imaginer une action qui est l’ouverture du port SSH pour l’IP à l’origine de la séquence.

Par ex, je décide que si une IP m’envoie un paquet SYN sur le port 342 en TCP, puis un paquet ACK sur le port 15161 en UDP, et enfin un paquet RST sur le port 63009 en TCP, alors j’ajoute une règle iptables qui autorise la connexion de cette IP sur le port 22 et qui forwarde cette connexion vers un autre ordinateur de façon transparente.

Le développeur se connecte alors en SSH sur mon ordinateur et se retrouve sur un autre comme par magie, de manière entièrement transparente pour lui. Simple, sûr et efficace.

Petite contrainte : il a faut un client « knock » qui envoie les bons paquets dans le bon ordre et au bon endroit. Il existe un binaire pour quasiment toutes les plateformes, Win32, Linux, MacOS, etc. Donc avant chaque connexion, il devra lancer une commande du genre :

./knock 293.15.12.12 ack:34562:tcp ack:961:udp rst:63009:tcp

Puis il pourra se connecter en SSH. Une fois la session terminée, il faut fermer la porte avec le même genre de commande. Pour se simplifier la vie on peut par exemple se faire 2 scripts, un « sshopen » et l’autre « sshclose » qui contiennent chacun la commande adéquate.

Linux : ne jamais faire service network restart

Extrait de conversation :

  • Olivier : Bon j’ai essayé de faire une correction mais rien ne fonctionne. Une fois le fichier modifié, il faut redémarrer le démon qui gère les échanges réseau ou pas ? Si oui, comment ?
  • Pascal : Il ne faut rien redémarrer du tout, c’est immédiat. Attends je vais voir ce qui cloche.
  • Olivier : Ah. C’est ça : « service network restart » ? Je vais essayer.
  • Pascal : Ma session SSH vient d’être coupée, c’est normal ?
  • Pascal : Non !!! Ne JAMAIS faire un network restart sur un serveur qui a des sockets ouvertes !!!
  • Olivier : Arrrrgh ! Plus rien. Je suppose que ça met du temps mais il reste injoignable au bout de 2 minutes… Je stresse un peu.
  • Olivier : Aaaaaargh ! http://www.acarat.com/ ne répond plus ! Putain je vais crever.
  • Pascal : Pas étonnant… Si tu avais attendu mes conseils 5 secondes de plus ça ne serait pas arrivé. Maintenant je n’ai plus accès au serveur, donc tu es tout seul.
  • Olivier : Bon eh bien la solution c’est d’aller à Marseille c’est ça ? Comment un service network restart peut-il tout planter ? Si tout le réseau redémarre bien, normalement tout est ok non ?
  • Pascal : Ce script touche toute la chaîne de configuration du réseau, des allocations mémoires de la pile IP jusqu’à la gestion et les options des interfaces physiques. Si tu fais un restart alors qu’il y a du trafic sur des sockets, tu as toutes les chances de planter les processus qui les utilisent avec un bon gros kernel panic à la clé.
    En résumé, tu es bon pour un voyage à Marseille.
    Même si le fait de redémarrer les services réseaux ne provoque pas de plantage, il reste tout de même les règles IPTables qui sont vidées en même temps que les interfaces sont arrêtées !
    Donc avec un network restart, tu fermes tout simplement ton firewall à tout nouveau paquet entrant.
    Si c’est vraiment ce dont il s’agit, il aurait fallu faire :
    service network restart; sleep 2; /etc/fw/iptables.sh
    Et donc en ayant patienté quelques secondes de plus, ça t’aurait épargné un A/R à Marseille et une interruption de service de tes sites Internet d’au moins 1h30.

La leçon du jour :

Ne rien toucher quand on ne connaît pas à 100% les implications d’une commande !

Linux : des droits spécifiques ftp ?

Comment donner des droits spécifiques ftp afin de renforcer (un peu) la sécurité de votre (vos) site(s) ?
Imaginons que l’on souhaite avoir plusieurs personnes qui travaillent sur le même site, qui veulent accéder aux sources via ftp, qui veulent pouvoir écrire dedans.
Imaginons aussi que l’on donne que le droit de lecture au processus apache, afin que si un pirate réussit à s’introduire dans le système via apache, il n’ait le droit que de lire les fichiers.
Configurons Linux de telle sorte que le processus apache soit lancé en tant qu’utilisateur apache.
Disons que nous avons besoin de travailler avec deux personnes :

  • Laurent (utilisateur = laurent)
  • Frédéric (utilisateur = frederic)

Il faut donc que :

  • l’utilisateur = laurent ait les droits en lecture et écriture dans un répertoire et sur des fichiers donnés ;
  • l’utilisateur = frederic ait les droits en lecture et écriture dans le même répertoire et sur les mêmes fichiers ;
  • l’utilisateur = apache ait les droits en lecture uniquement dans le même répertoire et sur les mêmes fichiers.

C’est simple.
Il faut créer un groupe pour les utilisateurs à qui on souhaite donner les droits de lecture et d’écriture. Appelons ce groupe happyfews. Il faut éditer le fichier /etc/groups et y ajouter :
happyfews:x:5000:laurent,frederic, etc,
avec tous les utilisateurs à qui l’on veut donner la possibilité de lire et d’écrire.
Puis sur le(s) répertoire(s) de travail, il faut appliquer les droits suivants :

  • chown apache <repertoire>
  • chgrp happyfews <repertoire>
  • chmod 570 <repertoire>

Ce qui signifie respectivement :

  • Le répertoire appartient à apache ;
  • Le répertoire appartient au groupe « happyfews » ;
  • Le groupe « happyfews » possède les droits de lecture + écriture, mais le propriétaire du répertoire lui-même n’a que le droit de lecture ;
  • Tout utilisateur autre que le propriétaire ou un membre du groupe n’a aucun accès.

Pour mémoire :
5=user:read+execute, 7=group:read+write+execute, 0=other:no access
Il ne restera ensuite qu’à ajouter/supprimer les utilisateurs qui font partie de ce groupe pour autoriser/refuser l’accès en écriture au(x) répertoire(s) concerné(s).