ace3@midway.uchicago.edu
.dd if=/dev/hda8 of=/etc/dosswap
gzip -9 /etc/dosswap
mkswap /dev/hda8 XXXXX
swapon -av
Ajoutez une ligne destin�e � cette partiton de swap dans le fichier /etc/fstab
swapoff -av
zcat /etc/dosswap.gz | dd of=/dev/hda8 bs=1k count=100
Dans le cas contraire il vous faudra invoquer ces commandes avant chaque fin
de session Linux (placer ces commandes dans un script...)>> Quels sont les avantages et inconv�nients de cette m�thode ?
Avantages : gain d'espace disponible sur le disque !
Inconv�nients : si l'�tape de restauration du fichier d'�change Windows n'est pas automatique il ne faudra pas n�gliger, sous Linux et avant chaque red�marrage "vers" Windows, de lancer les commandes charg�es de cette remise en place.
michael@actrix.gen.nz
.Voici une astuce dont j'ai eu besoin � quelques reprises.
La r�cup�ration d'un fichier texte par une personne d�sesp�r�e.
Si vous effacez un fichier texte par accident, par exemple un courrier �lectronique ou le produit d'une nuit de programmation, tout n'est pas perdu. Si le fichier a eu le temps d'aller jusqu'au disque, c'est � dire s'il a exist� pendant plus de 30 secondes, il est possible que son contenu se trouve encore sur la partition.
Vous pouvez le rechercher dans la partition en utilisant la commande grep.
Par exemple, r�cemment, j'ai effac� un courrier �lectronique par accident. J'ai imm�diatement cess� toute activit� qui aurait pu modifier le contenu de la partition : je me suis abstenu de sauvegarder quoi que ce soit, de compiler quoi que ce soit, etc. En d'autres occasions, je suis all� jusqu'� passer le syst�me en mode mono-utilisateur et d�monter le syst�me de fichiers.
J'ai ensuite utilis� la commande egrep sur la partition : dans
mon cas, le message se trouvait dans /usr/local/home/michael/
,
et donc d'apr�s la sortie de df, dans /dev/hdb5
.
sputnik3:~ % df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda3 18621 9759 7901 55% /
/dev/hdb3 308852 258443 34458 88% /usr
/dev/hdb5 466896 407062 35720 92% /usr/local
sputnik3:~ % su
Password:
[michael@sputnik3 michael]# egrep -50 'ftp.+COL' /dev/hdb5> /tmp/x
Je suis extr�mement prudent quand je manipule des partitions, donc j'ai bien pris le temps de m'assurer que je comprenais la syntaxe de cette commande AVANT de presser la touche Entr�e. Dans ce cas, le message contenait la mot "ftp", puis un peu de texte suivi du mot "COL". Le message faisait une vingtaine de lignes, donc j'ai utilis� -50 pour avoir toutes les lignes assez proches de la phrase. Il m'est d�j� arriv� d'utiliser -3000 pour �tre s�r de r�perer toutes les lignes d'un code source. J'ai redirig� le sortie de egrep vers une autre partition pour �viter d'�craser le message que je recherchais.
J'ai ensuite utilis� la commande strings pour examiner le r�sultat.
strings /tmp/x | less
Effectivement, le message �tait l�.
Cette m�thode peut ne pas �tre efficace si tout ou partie de l'espace disque a d�j� �t� r�utilis�.
Cette astuce n'est probablement utilisable que sur un syst�me mono-utilisateur. Sur un syst�me multi-utilisateurs avec beaucoup d'activit� sur les disques, l'emplacement que vous avez lib�r� peut tr�s bien d�j� avoir �t� r�utilis�. Et pour la plupart nous ne pouvons pas nous permettre d'enlever la machine de sous les pieds de nos utilisateurs d�s que nous avons besoin de r�cup�rer un fichier.
Sur mon syst�me personnel, cette astuce a �t� bien pratique � environ trois occasions ces quelques derni�res ann�es - g�n�ralement apr�s que j'ai d�truit accidentellement une partie de mon travail du jour. Si ce que je fais survit assez longtemps pour progresser de fa�on significative, je le sauvegarde sur une disquette, donc je n'ai pas souvent besoin de ce truc.
jadestar@rahul.net
.Utilisez le marqueur d'immutabilit�.
Juste apr�s avoir install� et configur� votre
syst�me, faites un tour dans /bin
, /sbin
,
/usr/bin
, /usr/sbin
, /usr/lib
et autres, et
n'h�sitez pas � vous servir de la commande "chattr
+i
". Appliquez-la aussi aux fichiers du noyau � la
racine. Maintenant, "mkdir /etc/.dist
" et copiez-y toute
l'arborescence contenue dans /etc
(je le fais en deux
�tapes en utilisant /tmp/etcdist.tar
pour �viter
la r�cursion). (Vous pouvez aussi vous contenter de
/etc/.dist.tar.gz
). Et placez-y un marqueur
d'immutabilit�.
Tout cela sert � limiter les d�g�ts que vous
pouvez faire en tant que root. Vous �viterez ainsi
d'�craser des fichiers avec une redirection mal
contr�l�e, et vous ne risquez pas de rendre le
syst�me inutilisable � cause d'une espace mal
plac�e dans une commande "rm -fr
" ; vous pouvez toujours
faire tr�s mal � vos donn�es, mais vos binaires
et vos biblioth�ques seront � l'abri.
De plus, cela pr�vient, ou du moins complique, l'exploitation d'un certain nombre de trous de s�curit� ; en effet, beaucoup d'attaques de ce type �crasent un fichier au moyen d'un quelconque programme SUID qui ne permet pas d'ex�cuter une commande arbitraire.
Le seul inconv�nient se pr�sente � l'installation
de divers logiciels syst�me. D'un autre c�t�,
�a emp�che l'�crasement accidentel de fichiers par
"make install
". Si vous oubliez de lire le Makefile et
d'appliquer chattr -i
aux fichiers qui doivent �tre
�cras�s (et aux r�pertoires auxquels vous voulez
ajouter des fichiers), le make �choue, et il suffit d'utiliser
chattr avant de le relancer. Vous pouvez aussi en profiter pour
d�placer vos anciens binaires, biblioth�ques et autres
dans un r�pertoire .old/
, les renommer, les archiver ou
autre.
Tout ce que vous rajoutez doit se trouver sous /usr/local
ou
/usr/local/`hostname`
!
Si votre distribution laisse /usr/local
vide, cr�ez
/usr/local/src
, /usr/local/bin
, etc. et utilisez-les. Si
votre distribution met des choses dans /usr/local
, cr�ez
/usr/local/`hostname`
et donnez-lui le mode +w pour le groupe
wheel (en plus, je le rends SUID et SGID pour m'assurer que les
membres du groupe wheel ne peuvent toucher qu'� leurs propres
fichiers et que tous les nouveaux fichiers vont appartenir au groupe
wheel).
Maintenant, forcez-vous � TOUJOURS placer
les nouveaux paquetages sous
/usr/local/src/.from/$OU_JE_L_AI_EU
(pour les fichiers .tar ou
autres) et � les compiler sous /usr/local/src
(ou
.../$HOSTNAME/src
). Assurez-vous qu'ils s'installent sous la
hi�rarchie locale. Si quelque chose *doit obligatoirement*
�tre install� dans /bin
ou /usr/bin
ou
autre, cr�ez un lien symbolique depuis la hi�rarchie
locale vers tout ce qui est install� ailleurs.
La raison de tout �a, m�me si �a repr�sente
plus de travail, est que �a permet de trouver facilement ce qui
doit �tre sauvegard� et r�install� en cas
de r�installation compl�te depuis le m�dia de
distribution (habituellement un CD � l'heure actuelle). En
utilisant un r�pertoire /usr/local/src/.from
, vous
gardez aussi une trace de la provenance de vos sources, ce qui est
utile pour trouver les mises � jour et qui peut s'av�rer
critique pour suivre les listes d'annonces de s�curit�.
Un de mes syst�mes personnels (celui que j'utilise) a �t� mont� avant que je n'applique moi-m�me cette politique. Je ne "sais" toujours pas en quoi il diff�re du syst�me de base "tel qu'install�". Et cela bien que je n'ai chang� que tr�s peu de choses quant � sa configuration et que je suis le *seul* � l'utiliser.
A contrario, tous les syst�mes que j'ai mis en place au travail (o� j'ai �t� bombard� administrateur syst�me) ont �t� configur�s de cette fa�on. Ils ont �t� administr�s par plusieurs personnes ext�rieures et autres membres du d�partement informatique, et ils ont subi de nombreuses mises � jour et installations de logiciels. Pourtant, j'ai une id�e tr�s pr�cise de ce qui a �t� rajout� *apr�s* l'installation et la configuration initiales.
dossey@ou.edu
.J'ai remarqu� quelques proc�dures difficiles ou superflues recommand�es dans les trucs et astuces du num�ro 12
NdT : Apparemment, cette section est tir�e de la Linux Gazette. Comme il y en a plusieurs, je vous adresse ce message.
#!/bin/sh
# lowerit
# convertit les noms de tous les fichiers du r�pertoire
# courant en minuscules
# n'affecte que les fichiers, pas les sous-r�pertoires
# demande confirmation avant d'�craser un fichier existant
for x in `ls`
do
if [ ! -f $x ]; then
continue
fi
lc=`echo $x | tr '[A-Z]' '[a-z]'`
if [ $lc != $x ]; then
mv -i $x $lc
fi
done
Voil� un long script. Je n'�crirais pas un script pour �a ; j'utiliserais plut�t la commande suivante :
for i in * ; do [ -f $i ] && mv -i $i `echo $i | tr '[A-Z]' '[a-z]'`;
done;
Ce contributeur dit qu'il a �crit le script de cette fa�on pour des raisons de lisibilit� (voir plus bas).
Pour l'astuce suivante, qui traite de l'ajout et de la suppression d'utilisateurs, Geoff s'en sort bien jusqu'� la derni�re �tape. Rebooter ? J'esp�re qu'il ne reboote pas � chaque fois qu'il supprime un utilisateur. Les deux premi�res �tapes suffisent. De toutes fa�ons, quels processus cet utilisateur pourrait-il laisser tourner ? Un bot IRC ? Tuez simplement les processus avec :
kill -9 `ps -aux |grep ^<nom d'utilisateur> |tr -s " " |cut -d " " -f2`
Par exemple, pour l'utilisateur foo:
kill -9 `ps -aux |grep ^foo |tr -s " " |cut -d " " -f2`
Cette question �tant class�e, passons au mot de passe de root oubli�.
La solution donn�e dans la Gazette est la plus universelle,
mais pas la plus facile. Aussi bien avec LILO qu'avec Loadlin, le
param�tre "single" permet de lancer directement le shell par
d�faut au d�marrage, sans entrer de login ni de mot de
passe. � partir de l�, il suffit de changer ou d'enlever
le mot de passe probl�matique, avant de taper "init 3
"
pour passer en mode multi-utilisateurs. De cette fa�on, un seul
reboot ; de l'autre, deux reboots.
Justin Dossey.
paul@geeky1.ebtech.net
Nous partons d'une source propre. Commencez par vous procurer le code source de sendmail. J'ai t�l�charg� la version 8.9.0, qui est comme vous pouvez le voir � la pointe du progr�s. Je l'ai r�cup�r�e depuis ftp.sendmail.org:/pub/sendmail/sendmail-8.9.0.tar.gz
Il p�se � peu pr�s un m�ga-octet, et sachant que j'utilise la version 8.7.6, je crois que �a vaut le co�t. Si �a marche, vous en entendrez s�rement parler ; sinon, je n'aurai plus de courrier et je ne pourrai pas distribuer la nouvelle version de ce HOWTO :)
Maintenant que vous avez t�l�charg� le source,
d�compactez-le. Cela va cr�er un sous-r�pertoire
sendmail-8.9.0
dans le r�pertoire courant. Placez-vous
dans ce sous-r�pertoire et lisez les fichiers README
et
RELEASE_NOTES
(et soyez �poustoufl� par toutes les
am�liorations qu'ils ont apport�es). Maintenant,
placez-vous dans src
. C'est l� que vous allez faire le
plus gros du travail.
Une remarque au passage : Sendmail est un programme petit, puissant
et bien �crit. Le binaire sendmail
lui-m�me a mis
moins de 5 minutes � compiler sur mon 5x86 133 avec 32 Mo de
RAM ! La totalit� de la compilation et de l'installation (sans
compter la configuration) ont pris moins de 15 minutes !
Je n'utilise pas BIND sur mon syst�me, donc j'ai cherch� les lignes suivantes :
# ifndef NAMED_BIND
# define NAMED_BIND 1 /* use Berkeley Internet Domain Server */
# endif
et j'ai remplac� le 1 par un 0:
# ifndef NAMED_BIND
# define NAMED_BIND 0 /* use Berkeley Internet Domain Server */
# endif
Sur la Debian 1.3, db.h
est install� par d�faut
dans /usr/include/db
, au lieu de /usr/include
o�
sendmail esp�re le trouver. Placez-vous successivement dans les
sous-r�pertoires src
, mailstats
, makemap
,
praliases
, rmail
et smrsh
et �xecutez la
commande suivante :
./Build -I/usr/include/db
Ensuite, cd ..
et tapez make install
. Voil� ! La
version 8.9.0 de Sendmail doit maintenant �tre install�e !
Bien s�r, �a suppose que vous avez d�j�
votre configuration d'origine. Pour que tout marche bien sur mon
syst�me, comme j'h�berge des listes de diffusion
gratuites utilisant majordomo, j'ai ajout� la ligne suivante au
d�but de mon /etc/sendmail.cf
:
O DontBlameSendmail=forwardfileinunsafedirpath, forwardfileinunsafedirpathsafe
Sendmail 8.9.0 est � l'heure actuelle plut�t bavard
� propos des permissions des r�pertoires et des
fichiers, et il va se plaindre � propos des r�pertoires
et des fichiers qui autorisent l'acc�s en �criture pour
le groupe ou pour tout le monde parmi les fichiers d'alias ou
.forward
. Bien qu'il ne soit pas recommand� d'inhiber ces
avertissements, je suis toujours seul � la console et j'ai
trouv� que ce trou de s�curit� mineur
n'�tait en fait pas g�nant. C'est vous qui voyez.
jadestar@rahul.net
Cr�ez et tenez � jour un fichier
/README.`hostname`
ou /etc/README.`hostname`
[ ou �ventuellement
/usr/local/etc/README.`hostname`
- le
r�dacteur ]
Absolument, � compter du premier jour de l'administration
d'un syst�me, prenez des notes dans un fichier journal. Vous
pouvez mettre "vi /README.$(hostname)" sur une ligne du fichier
.bash_logout
de root. Une autre fa�on de faire est
d'�crire un script su
ou sudo
qui fait quelque chose
comme �a :
function exit \
{ unset exit; exit; \
cat ~/tmp/session.$(date +%y%m%d) \>> /README.$(hostname) && \
vi /README.$(hostname)
}
script -a ~/tmp/session.$(date +%y%m%d)
/bin/su.org -
(utilise la commande tap�e pour cr�er une trace de la session et cr�e une fonction pour automatiser la mise � jour du fichier journal).
J'admets que je n'ai pas implant� cette automatisation - jusqu'� maintenant je me suis repos� sur ma discipline. Cependant j'ai envisag� l'id�e (au point d'�crire les scripts et les fonctions que vous avez sous les yeux). Une chose qui me retient est la commande "script" elle-m�me. Je pense qu'il va falloir que je me procure les sources et que je rajoute une paire de param�tres (pour arr�ter l'enregistrement du script depuis la ligne de commandes) avant de me mettre � utiliser �a.
Ma derni�re suggestion (pour cette fois) :
La variable PATH de root devrait contenir PATH=~/bin
.
C'est tout. Rien d'autre dans le PATH de root. Tout ce que root peut
faire est fourni par un lien symbolique dans ~/bin
, un alias,
une fonction shell, un script ou un binaire situ� dans
~/bin
, ou bien la commande est tap�e avec un chemin
d'acc�s explicite.
De cette fa�on, toute personne utilisant le compte root se rend
compte (parfois douloureusement) � quel point elle fait
confiance aux binaires. L'administrateur avis� d'un
syst�me multi-utilisateurs va en plus parcourir
r�guli�rement son r�pertoire ~/bin
et ses
fichiers ~/.*history
pour y chercher des
r�p�titions et des moyens de les contourner.
L'administrateur vraiment motiv� va rep�rer les
encha�nements qui peuvent �tre automatis�s, les
endroits o� des v�rifications peuvent �tre
ajout�es, et les t�ches pour lesquelles les
privil�ges de root peuvent �tre abandonn�es (comme
lancer un �diteur, un agent de transport de courrier
�lectronique ou autre gros programme pouvant ex�cuter
des scripts qui *pourraient* �tre inclus dans des fichiers de
donn�es - comme vi (./.exrc
) ou emacs (./.emacs
)
ou m�me, plus insidieux, $EXINIT et les macros contenues au
d�but ou � la fin des documents). Bien s�r, les
commandes de ce genre peuvent �tre lanc�es avec quelque
chose comme �a :
cp $donn�es $r�pertoire_utilisateur/tmp
su -c $commande_d_origine $param�tres
cp $r�pertoire_utilisateur/tmp $donn�es
(... o� les d�tails d�pendent de la commande).
Ces derni�res pr�cautions sont pour la plupart superflues pour la machine personnelle ou la station "mono-utilisateur". Mais elles repr�sentent une tr�s bonne mani�re d'administrer un gros syst�me multi-utilisateurs, particuli�rement dans le cas d'un acc�s public (comme les machines de netcom).
xdm
pour qu'il permette de choisir le syst�me h�te ? Arrigo Triulzi, a.triulzi@ic.ac.uk
./usr/bin/X11/xdm
exec /usr/bin/X11/X -indirect hostname
J'ajoute cette section apr�s avoir su� une semaine durant sur ce probl�me !
Attention : certaines anciennes versions de la distribution SLS (1.1.1) exigent qu'un param�tre "-nodaemon" accompagne l'invocation d'xdm. Les version ult�rieures ne pr�sentent PAS cette caract�ristique.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:24