Verder Terug Inhoud

3. Gedetailleerde Tips

3.1 Delen van swappartities tussen Linux en Windows. Tony Acero, ace3@midway.uchicago.edu

  1. Formatteer de partitie als een dospartitie, en creëer er het Windows swapbestand op, maar draai windows nog niet. (Je wilt het swapbestand op het moment nog leeghouden, zodat het goed comprimeert).
  2. Boot linux en bewaar de partitie in een bestand. Als de partitie bijvoorbeeld /dev/hda8 is:
    dd if=/dev/hda8 of=/etc/dosswap
    
  3. Comprimeer het dosswap bestand; aangezien het praktisch allen nullen zijn, zal het zeer goed comprimeren
    gzip -9 /etc/dosswap
    
  4. Voeg het volgende toe aan het /etc/rc bestand om de swapspace onder Linux voor te bereiden en te installeren: XXXXX is het aantal blokken in de swappartitie
    mkswap /dev/hda8 XXXXX
    swapon -av   
    
    Zorg dat je een regel toevoegt in het /etc/fstab bestand voor de swappartitie
  5. Als het package init/reboot /etc/brc of /sbin/brc ondersteunt, voeg je het volgende toe aan /etc/brc, doe dit anders met de hand, wanneer je in dos|os/2 boot en je de swappartitie weer wilt omzetten naar de dos/windows versie:

swapoff -av
zcat /etc/dosswap.gz | dd of=/dev/hda8 bs=1k count=100
# Merk op dat hiermee slechts de eerste 100 blokken naar de partitie worden # teruggeschreven. # Ik heb door ervaring gemerkt dat dit voldoende is

> Wat zijn hier de voors en tegens van?

Voors: je bespaart een substantiële hoeveelheid schijfruimte

Tegens: Als stap 5 niet automatisch gaat, dan moet je eraan denken dit met de hand te doen, en het vertraagt het rebootproces met een nanoseconde :-)

3.2 Wanhopige Undelete. Michael Hamilton, michael@actrix.gen.nz

Hier is een truuk die ik al een paar keer heb moeten gebruiken

Als je per ongeluk een tekstbestand verwijdert, zoals bijvoorbeeld wat email, of het resultaat van een programmeersessie op de late avond, hoeft alles niet verloren te zijn. Als het bestand het ooit naar disk haalde, d.w.z. dat het daar meer dan 30 seconden was, dan kan het zijn dat de inhoud nog steeds op de diskpartitie voorkomt.

Je kunt de opdracht grep gebruiken om de ruwe diskpartitie te doorzoeken op de inhoud van het bestand.

Ik verwijderde bijvoorbeeld onlangs per ongeluk een deel van m'n email. Dus staakte ik onmiddellijk mijn activiteiten die deze partitie konden wijzigen: in dit geval zag ik gewoon af van het opslaan van mijn bestanden of het uitvoeren van compilaties, enz. Onder andere omstandigheden heb ik me de moeilijkheid op de hals gehaald door het systeem in single user modus te brengen en het bestandssysteem te unmounten.

Ik paste toen de opdracht egrep toe op de diskpartitie: in mijn geval bevond het emailbericht zich in /usr/local/home/michael/, dus aan de uitvoer van df, kon ik zien dat dit op /dev/hdb5 was.

  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
 
Nu ben ik extreem voorzichtig wanneer ik met diskpartities aan de gang ga, dus ik pauzeerde om er zeker van te zijn dat ik de syntax van de opdracht begreep VOORDAT ik de return indrukte. In dit geval bevatte de email het woord 'ftp' gevolgd door wat tekst gevolgd door het woord `COL'. Het bericht bestond uit ongeveer 20 regels, dus gebruikte ik -50 om alle regels rondom de woorden te krijgen. Voorheen gebruikte ik altijd -3000 om er zeker van te zijn dat ik alle regels kreeg van een of andere broncode. Ik stuurde de uitvoer van egrep door naar een andere diskpartitie. Hiermee voorkwam ik dat er over het bericht heengeschreven zou worden waar ik naar aan het zoeken was.

Vervolgens gebruikte ik strings om me te helpen de uitvoer te inspecteren.

   strings /tmp/x | less
 
Zeker weten dat de email zich daarin bevond.

Deze methode is niet betrouwbaar; alle of een deel van de schijfruimte kan reeds zijn hergebruikt.

Deze truuk is waarschijnlijk alleen bruikbaar op single user systemen. Op multi-user systemen met nogal wat diskactiviteit, kan de ruimte die je hebt vrijgemaakt reeds weer zijn gebruikt. En de meesten van ons kunnen niet zomaar de box vandaan trekken bij onze gebruikers wanneer we ooit een bestand moeten herstellen.

Op mijn systeem thuis is deze truuk me in de afgelopen paar jaar bij ongeveer drie gelegenheden van pas gekomen - gewoonlijk wanneer ik per ongeluk wat van het werk van die dag verwijderde. Als waar ik aan werk het overleeft tot een punt waarvan ik het gevoel heb dat ik een belangrijke voortgang hebt geboekt, wordt er op een diskette een backup van gemaakt, dus ik heb deze truuk nog niet zo vaak nodig gehad.

3.3 Hoe gebruik te maken van de immutable vlag. Jim Dennis, jadestar@rahul.net

Gebruik de Immutable Flag

Neem direct na de installatie en configuratie van je systeem de /bin, /sbin, /usr/bin, /usr/sbin en /usr/lib door (plus nog een paar van de andere gebruikelijke verdachte bestanden en maak royaal gebruik van de opdracht 'chattr +i '. Voeg dat ook toe aan de kernelbestanden in root. Nu 'mkdir /etc/.dist/' kopieer alles vanuit /etc/ naar beneden (Ik doe dit in twee stappen met /tmp/etcdist.tar ter voorkoming van recursie) in die directory. (Optioneel kun je gewoon /etc/.dist.tar.gz aanmaken) -- en dat als immutable markeren.

De reden voor dit alles is het beperken van de schade die je als root kunt aanrichten. Je zal geen bestanden overschrijven door een misplaatst omleidingsteken, en je zal het systeem niet onbruikbaar achterlaten door een verdwaalde spatie in een 'rm -fr' opdracht (je kunt nog steeds heel wat schade aan je gegevens aanrichten -- maar je libs en bins zullen veiliger zijn.

Dit maakt ook een diversiteit aan beveiligings- en denial of service uitbuitingen óf onmogelijk óf moeilijker (aangezien veel daarvan erop vertrouwen een bestand te kunnen overschrijven via de acties van een of ander SUID programma die *niet voorziet in een willekeurige shellopdracht*).

Het enige ongerief hierbij onstaat bij het bouwen en uitvoeren van een 'make install' op diverse soorten systeembinary's. Aan de andere kant voorkomt het ook dat een 'make install' de bestanden overschrijft. Wanneer je vergeet de Makefile in te lezen en chattr -i toe te passen op de bestanden die op het punt staan te worden overschreven (en de directory's waaraan je bestanden toe wilt voegen) -- mislukt de make. Je past er dan gewoon de chattr opdracht op toe en start het opnieuw op. Je kunt die gelegenheid ook gebruiken om je oude bin's, libs of wat dan ook naar een .old/ directory te verplaatsen of ze hernoemen of er tar op toepassen of wat dan ook.

3.4 Een suggestie waar nieuwe software te plaatsen. Jim Dennis, jadestar@rahul.net

Alle nieuwe software begint onder /usr/local! of /usr/local/`hostname`

Als je distributie /usr/local leeg laat, creëer dan een /usr/local/src, /usr/local/bin enz en gebruik dat. Plaatst de distributie zaken in de /usr/local structuur dan wil je wellicht een 'mkdir /usr/local/`hostname`' uit laten voeren en er de groep 'wheel' +w aan toekennen (ik maak het ook SUID en SGID om ervan verzekerd te zijn dat elk lid van de wheel groep daaronder alleen iets met eigen bestanden kan doen, en dat alle aangemaakte bestanden zullen toebehoren aan de 'wheel' groep.

Disciplineer jezelf nu om *ALTIJD! ALTIJD! ALTIJD!* nieuwe packages onder /usr/local/src/.from/$WAAR_IK_HET_VANDAAN_HAALDE/ plaatst (voor de .tar of wat voor bestanden dan ook) en bouw ze onder /usr/local/src (of .../$HOSTNAME/src). Zorg dat ze onder de lokale hiërarchie worden geïnstalleerd. Plaats een symlink vanuit de lokale hiërarchie naar elk element dat ergens anders naartoe gaat als het *beslist moet" worden geïnstalleerd in /bin, /usr/bin of elders.

De reden hiervoor -- ook als is het wat meer werk -- is dat het helpt isoleren waarvan een backup moeten worden gemaakt en wat moet worden terruggezet van een backup of opnieuw geïnstalleerd in geval van een volledige herinstallatie vanaf de distributiemedia (tegenwoordig gewoonlijk van een CD). Door gebruik te maken van een /usr/local/.from directory houd je ook een informele log bij van waar je bronnen vandaan komen. -- wat helpt wanneer je op zoek bent naar nieuwe updates -- en van groot belang kan zijn bij het monitoren van de security announcement lists.

Een van mijn systemen thuis werd samengesteld voordat ik deze maatregelen zelf toepaste. Ik heb nog maar erg weinig met de configuratie van mijn thuissysteem gedaan en ik ben de *enige* persoon die het ooit gebruikt.

Als contrast zijn de systemen die ik op het werk heb ingesteld (toen mij hier de rol van systeembeheerder werd toevertrouwd) allen op deze manier ingesteld --- beheerd door veel contractanten en andere MIS mensen, zijn er een groot aantal upgrades en installatie van packages op geïnstalleerd. Niettemin heb ik een zeer goede indruk welke elementen precies werden geplaatst *na* de initiële installatie en configuratie.

3.5 Alle bestanden in een directory naar kleine letters omzetten. Justin Dossey, dossey@ou.edu

Ik nam notitie van een paar overmatig moeilijke of onnodige procedures aanbevolen in de 2c tips sectie van Issue 12. Aangezien er meer van zijn, stuur ik het je op:


#!/bin/sh
         # lowerit
         # zet alle bestandsnamen in de huidige directory om naar kleine letters
         # werkt alleen met gewone bestanden--wijzigt geen directorynamen
         # zal vragen om verificatie voor een bestaand bestand te overschrijven
         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

Wauw. Dat is een lang script. Ik zou daarvoor geen script schrijven, ik zou in plaats daarvan deze opdracht gebruiken:
for i in * ; do [ -f $i ] && mv -i $i `echo $i | tr '[A-Z]' '[a-z]'`;
done;
op de opdrachtregel.

Degene die het aanleverde zei dat de wijze waarop hij het script schreef hij dit voor de leesbaarheid deed (zie hieronder).

Op naar de volgende tip, deze over het toevoegen en verwijderen van gebruikers. Het gaat Geoff goed af tot aan de laatste stap. Reboot? Tjonge, ik hoop niet dat hij reboot elke keer als hij een gebruiker verwijdert. Het enige dat je hoeft te doen, is het uitvoeren van de eerste twee stappen. Welk type processen zou die gebruiker hebben lopen? Een irc bot? Het killen van de processen met een simpel

kill -9 `ps -aux |grep ^<username> |tr -s " " |cut -d " " -f2`
Voorbeeld, gebruikersnaam is foo
kill -9 `ps -aux |grep ^foo |tr -s " " |cut -d " " -f2`
Laten we daarmee te hebben afgerekend, verdergaan met het vergeten root-wachtwoord.

De oplossing gegeven in de Gazette is de meest universele, maar niet de eenvoudigste. Met zowel LILO als loadlin, kan met het opgeven van de bootparameter "single" direct in de standaardshell zonder login of password prompt worden geboot. Vanaf daar, kan met elk wachtwoord wijzigen of verwijderen voor het typen van "init 3" om in multiuser modus te starten. Aantal reboots: 1 De andere manier Aantal reboots: 2

Justin Dossey

3.6 Hoe Sendmail upgraden Paul Anderson, paul@geeky1.ebtech.net

We beginnen vanuit de ruwe, zuivere broncode. Zorg eerst dat je aan de sendmail broncode komt. Ik heb versie 8.9.0, wat zoals je op zal vallen, het nieuwste van het nieuwste is. Ik haalde het vanaf ftp.sendmail.org:/pub/sendmail/sendmail.8.9.0.tar.gz

Het is ongeveer 1Meg, en in overweging nemend dat ik 8.7.6 draai, denk ik dat het de moeite waard is. Als dit werkt, zul je dit ongetwijfeld te horen krijgen, anders kan ik de nieuwe HOWTO versies er niet uitkrijgen zonder e-mail:)

Pak het uit, nu je de broncode hebt. Er zal in de huidige directory een dir met de naam sendmail-8.9.0 worden aangemaakt. Ga naar die directory en lees de bestanden README en RELEASE_NOTES (en verbaas je over de updates die zijn gedaan). Ga nu met cd naar src. Hier zal je meeste werk worden uitgevoerd.

Een beknopte notitie: Sendmail is een klein, krachtig en goed geschreven programma. De sendmail binary zelf compileert in minder dan 5 minuten op mijn 5x86 133 met 32Megs RAM! De gehele compilatie en installatie nam (zonder config) minder dan 15 minuten in beslag!

Normaal gesproken gebruik ik BIND niet op mijn systeem, dus ik trof de regels


# ifndef NAMED_BIND
#  define NAMED_BIND    1       /* gebruik Berkeley Internet Domain Server */
# endif

aan en wijzigde de 1 in een 0, ala:


# ifndef NAMED_BIND
#  define NAMED_BIND    0       /* gebruik Berkeley Internet Domain Server */
# endif

Onder Debian 1.3.1, is db.h standaard geïnstalleerd in /usr/include/db, in plaats van in /usr/include, waar sendmail het hoopt te vinden. Ga naar de src, mailstats, makemap, praliases, rmail en smrsh directory's en voer de volgende opdracht uit:

 ./Build -I/usr/include/db

Zodra je dat hebt gedaan, cd .. en typ make install. Dat is het! Sendmail versie 8.9.0 zou nu moeten zijn geïnstalleerd! Dit uiteraard in de veronderstelling dat je reeds een originele configuratie hebt. Om alles op mijn systeem soepel te laten werken, moest ik het volgende aan het begin van /etc/sendmail.cf toevoegen, aangezien ik vrije mailinglists host voor mensen die majordomo gebruiken:


O DontBlameSendmail=forwardfileinunsafedirpath, forwardfileinunsafedirpathsafe

Sendmail 8.9.0 is tegenwoordig nogal eigenzinnig als het gaat om directory- en bestandspermissies, en het zal meldingen geven over dirs en bestanden in aliases of .forward bestanden die voor de groep of wereld schrijfbaar zijn. Ondanks dat het niet verstandig is deze eigenzinnigheid te deactiveren, draai ik het als enige persoon op de console en ik vond dat het ok was dit kleine beveiligingsgat toe te staan. YMMV.

3.7 Een aantal tips voor nieuwe systeembeheerders. Jim Dennis, jadestar@rahul.net

Creëer en onderhoud een /README.`hostname` en/of een /etc/README.`hostname` [Of mogelijk /usr/local/etc/README.`hostname` -Maint. ]

Maak vanaf *de eerste dag* dat je een systeem beheert, notities in een online logbestand. Je zou een "vi /README.$(hostname)" een regel in root's  /bash_logout aan kunnen maken. Een andere manier om dit te doen is het schrijven van een su of sudo script die iets dergelijks doet als in:

                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 -

(gebruik de opdracht typescript om een sessielog te creëren en maak een functie aan voor het automatisch toevoegen en bijwerken van de log).

Ik geef toe dat ik het automatiseren van dit beleid niet heb geïmplementeerd. Ik vertrouwde tot dusverre op zelfdiscipline. Ik heb echter met het idee gespeeld (zelfs tot aan het punt vooraf intypen van de scripts en shellfuncties zoals je ze hier ziet). Een ding dat me weerhoudt is de 'script' opdracht zelf. Ik denk dat ik een paar opdrachtregelparameters aan de broncode toe moet voegen (voor een pause/stop van het scriptopname vanaf de opdrachtregel) voordat ik ze aanlever voor gebruik.

Mijn laatste suggestie (voor deze ronde):

Het pad van root zou moeten bestaan uit 'PATH= /bin'

Dat is alles. Niets meer in het pad van root. Alles wat root doet wordt geleverd door een symlink vanuit  /bin of door een alias of shellfunctie of is een script of binary in  /bin, of wordt uitgetikt met een expliciet pad.

Dit maakt iedereen draaiend als root zich bewust (soms pijnlijk bewust) van hoe hij/zij binaire bestanden vertrouwt. De verstandige beheerder van een multi-user host zal periodiek zijn  /bin en  /.*history bestanden doorzoeken op bepaalde patronen en loopholes.

De echt gemotiveerde beheerder zal reeksen ontdekken die kunnen worden geautomatiseerd, plaatsen waar veiligheidscontroles kunnen worden ingevoegd, en taken waarvoor "root" privileges tijdelijk zouden moeten worden vermeden (opstarten van editors, MTA's en andere grote interactieve programma's met uitgebreide scriptmogelijkheden die in transparante of gegevensbestanden, *zouden* kunnen worden ingesloten zoals de befaamde vi ./.exrc en emacs ./.emacs en de zelfs meer verraderlijke $EXINIT en ingesloten header/footer macro's). Vanzelfspreken kunnen dergelijke opdrachten worden uitgevoerd met iets als:

                cp $data $some_users_home/tmp
                su -c $origcommand $whatever_switches
                cp $some_users_home/tmp $data
(...waar de details afhangen van de opdracht).

De meeste van deze voorzorgsmaatregelen zijn voor de home- of voor een "single" user werkstation wat overdreven, maar vormen een erg goed beleid voor de beheerder van een multi-user systeem --- in het bijzonder wordt een publiek toegankelijk systeem (zoals die van netcom).

3.8 Hoe xdm's chooser te configureren voor hostselectie Arrigo Triulzi, a.triulzi@ic.ac.uk

  1. Wijzig het bestand waarmee xdm wordt opgestart, naar alle waarschijnlijkheid is dit /etc/rc/rc.6 of /etc/rc.local), zodanig dat in de xdm opstartsectie de volgende regels komen te staan:
            
    /usr/bin/X11/xdm
    exec /usr/bin/X11/X -indirect hostname
    
  2. Wijzig /usr/lib/X11/xdm/Xservers en haal het commentaarteken weg voor de regel die de server start op de lokale machine (d.w.z. de regel beginnend met 0:)
  3. Reboot de machine

Ik voeg dit toe omdat het me ongeveer een week kostte om alle problemen de kop in te drukken toen ik het wanhopig probeerde in te stellen voor mijn eigen subnet.

Voorbehoud: met oude SLS (1.1.1) kun je om een of andere reden een -nodaemon weglaten na de xdm regel -- dit werkt NIET met latere uitgaven.


Verder Terug Inhoud