Mots-clé : système

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« ).

/mot-cle/systeme/

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 .

/mot-cle/systeme/

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.

/mot-cle/systeme/

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 !

/mot-cle/systeme/

Linux : utilisation de SCP (mémo simple)

SCP (= Secure Copy Protocol) donne la possibilité de transférer des fichiers entre des machines UNIX via le protocole sécurisé SSH. C’est rapide et c’est fait en toute sécurité.

  • Transférer le fichier file.txt vers le répertoire en cours de la machine 192.168.0.12 :
    scp file.txt noob@192.168.0.12:.
    (NB : le « . » est important à la fin, cela indique que le répertoire de destination est le répertoire en cours)
  • Récupérer file.txt situé sur /home/noob sur la machine 192.168.0.12 et le mettre dans le répertoire en cours (important : n’oubliez pas le « . » à la fin qui indique le répertoire en cours) :
    scp noob@192.168.0.12:/home/noob/file.txt .
  • Récupérer tous les fichiers pdf situés dans le répertoire /usr/local de la machine 192.168.0.12 et les mettre dans /var/www :
    scp noob@192.168.0.12:/usr/local/*pdf /var/www
  • Transférer tout le repertoire /var/www (en récursif) vers la machine 192.168.0.12 dans le repertoire /incoming :
    scp -r /var/www noob@192.168.0.12:/incoming

/mot-cle/systeme/

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).

/mot-cle/systeme/

Linux : le gestionnaire par défaut : kdm ou gdm ?

Comment choisir son gestionnaire par défaut : kdm ou gdm ?
Il faut être sûr(e) que les deux paquets sont installés :

  1. gdm
  2. kdm

Ensuite il suffit de faire :

  1. Pour forcer à démarrer en gdm (=Gnome Desktop Manager)
    sudo dpkg-reconfigure gdm
  2. Pour forcer à démarrer en kdm (=Kde Desktop Manager)
    sudo dpkg-reconfigure kdm

/mot-cle/systeme/