ace3@midway.uchicago.edu
dd if=/dev/hda8 of=/etc/dosswap
gzip -9 /etc/dosswap
mkswap /dev/hda8 XXXXX
swapon -av
swapoff -av
zcat /etc/dosswap.gz | dd of=/dev/hda8 bs=1k count=100
>> Hva er fordelene og ulempene ved dette?
Fordel: du sparer en stor del av diskplassen din.
Ulempe: Hvis trinn 5 ikke er automatisk, må du huske å gjøre det manuelt. Det forsinker også reboot prosessen din med et nanosekund :-)
michael@actrix.gen.nz
Her er et triks jeg er blitt nødt til å bruke et par ganger.
Når man desperat trenger å få tilbake en slettet fil.
Hvis du tilfeldigvis sletter en fil ved et uhell. For eksempel e-post eller programmeringsfiler du har brukt en hel natt på. Slapp av, filen trenger ikke nødvendigvis å være fortapt. Hvis filen var lagret på disken og lå på der i over 30 sekunder, kan dets innhold fremdeles være intakt.
Du kan nemlig bruke grep kommandoen for å søke gjennom en rå diskpartisjon etter filens innhold.
Nylig slettet jeg ved et uhell en viktig e-post. Uten å nøle stoppet jeg all aktivitet som på noen måte kunne endre på partisjonen: i dette tilfellet ventet jeg bare med å lagre filer eller å kompilere noe, osv. Ved andre tilfeller har jeg fått systemet ned til enbrukermodus og avmontert filsystemet.
Deretter brukte jeg egrep kommandoen på partisjonen: i mitt tilfelle var e-posten tidligere i katalogen /usr/local/home/michael/, så utifra utskriften fra df kunne jeg se at det var i /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
Deretter brukte jeg strings for å se igjennom dataet.
strings /tmp/x | less
Denne metoden kan man ikke stole fullt på, siden noe av diskplassen kan allerede ha blitt igjenbrukt.
Trikset er nok best på enbrukersystemer. På flerbrukersystemer med stor diskaktivitet, kan diskplassen raskt bli igjenbrukt. Du kan jo heller ikke begynne å rote med systemet for mye når mange brukere er på hver gang du trenger en slettet fil tilbake.
På min hjemmedatamaskin har jeg benyttet dette trikset omtrent tre ganger i de siste årene - vanligvis når jeg har ved en feil slettet noe arbeid. Hvis jeg har arbeidet med noe så lenge at jeg fornøyd med det, kopierer jeg det vanligvis til en diskett. Derfor har jeg ikke trengt å benytte trikset så mye.
jadestar@rahul.net
Bruken av Immutable attributten
Rett etter du har installert og konfigurert systemet ditt gå gjennom /bin, /sbin, /usr/bin, /usr/sbin og /usr/lib og et par andre kataloger hvis du vil. I disse katalogene bør du bruke 'chattr +i' kommandoen liberalt. Bruk også denne kommandoen på f.eks kjernefilene i roten. Nå tar du en 'mkdir /etc/.dist/'. Kopier så hele katalogen /etc inn i denne katalogen. (Du kan godt lage en /tmp/etcdist.tar, som jeg gjør). -- etterpå merker du /etc/.dist/ som "immutable".
Grunnen til bruken av denne kommandoen er til å begrense skaden du kan gjøre mens du er logget inn som root. Du kan ikke lenger overskrive filer som vanlig og du kan ikke slette hele systemet med en 'rm -fr' kommando. (Du kan likevel gjøre stor skade på dataene dine, men dine biblioteker og binærfiler vil bli tryggere.)
Dette gjør også diverse sikkerhets- og såkale 'Denial Of Service' -hull mye vanskeligere eller umulig. (Siden mange av dem avhenger av å overskrive en fil ved hjelp av en bug i et SUID program som *ikke tilbyr en egenmektig shell kommando*).
Den eneste ulempen med dette er når du kompilerer noe og kjører 'make install' som skal overskrive noen viktige binærfiler. På en annen side kan det være bra at den beskytter 'make install' i å overskrive filene. Når du har glemt å lese Makefile og 'chattr -i'et filene som skal bli overskrevet -- mislykkes make og du bruker chattr kommandoen og prøver igjen. Du kan også flytte dine gamle binærfiler, biblioteker eller hva du vil til en .old/ katalog. Du kan også skifte navn på filene, pakke dem ned eller hva du nå vil.
jadestar@rahul.netAlle nye ting legges i /usr/local! eller i /usr/local/`hostname`
Hvis distribusjonen din bare lager en tom /usr/local katalog, kan du bare lage dine egne /usr/local/src, /usr/local/bin osv. kataloger og bruke dem. Hvis distribusjonen din har puttet noe i /usr/local katalogtreet, kan du gjøre en 'mkdir /usr/local/`hostname`' og gi 'wheel' gruppen skriverrettigheter (+w) til det. (Jeg gjør det også til SUID og SGID for å forsikre meg om at hvert medlem av wheel gruppen kan bare tukle med sine egne filer derunder, og at alle filer som blir laget der vil høre til 'wheel' gruppen.
Du må huske å *ALLTID! ALLTID! ALLTID* legge nye pakker under /usr/local/src/.from/$HVOR_JEG_FIKK_DEN_FRA/ (for .tar filer og lignende) og kompiler/bygg dem under /usr/local/src (eller .../$HOSTNAME/src). Forsikre deg om at programmet installeres under det lokale katalogtreet. Hvis det absolutt *må* installeres i /bin eller /usr/bin eller et annet sted -- dra en symlink fra det lokale katalogtreet til hvert element som er et annet sted.
Grunnen til dette (selv om det er mer arbeid) -- er at det hjelper å isolere hva som må sikkerhetskopieres og reinstalleres hvis hele systemet må reinstalleres (vanligvis fra en CD i disse dager). Ved å bruke en /usr/local/.from katalog får du også en logg om hvor kodene dine kommer fra -- noe som hjelper når det kommer oppdateringer for programmet. Det kan være svært nødvendig når du leser sikkerhetshullslistene.
En av mine datamaskiner hjemme (den jeg ringer fra) ble satt sammen før jeg visste om disse reglene. Jeg er enda ikke helt klar over alle måtene det skiller seg ut fra et standard "as installed" system. Dette er til tross for at jeg har gjort veldig lite med hjemmemaskinen min sin konfigurasjon og jeg er den eneste personen som noensinne bruker den.
I kontrast med dette har andre systemer jeg har konfigurert på jobben (da jeg bar rollen som systemansvarlig der) har de alle blitt konfigurert av mange ingeniører og andre MIS folk. Maskinenene har mange ganger foretatt en installasjon av et program og har mange ganger blitt oppgradert. Uansett har jeg en temmelig god anelse om hvilke elementer som ble installert *etter* den første installasjonen og konfigurasjonen.
dossey@ou.edu
Jeg har lagt merke til mange vanskelige eller unødvendige prosedyrer anbefalt av 2c tips seksjonen i Linux Gazette utgave 12. Siden det fins mer enn en, sender jeg deg en:
#!/bin/sh
# "lowerit"
# * konverterer alle filnavn i den nåværende katalogen til små
# bokstaver.
# * virker bare på vanlige filer -- skifter ikke
# navn på kataloger.
# * vil spørre etter verifisering før det overskriver en fil
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
for i in * ; do [ -f $i ] && mv -i $i `echo $i | tr '[A-Z]' '[a-z]'`;
done;
Bidragsyteren sier at han han skrev skriptet som han gjorde for at det skulle være lett å forstå (se nedenfor).
I det neste tipset får du lære om å legge til å fjerne brukere, Ola greier seg helt fint helt til det siste trinnet. Re-starte maskinen? Håper da ikke han starter maskinen på nytt hver gang han fjerner en bruker. Alt du trenger å gjøre er å følge de to neste trinnene. Forresten, hva slags prosesser vil en slik bruker ha kjørende uansett? En irc bot? For å drepe prosessene gjør man slik:
kill -9 `ps -aux |grep ^<brukernavn> |tr -s " " |cut -d " " -f2`
kill -9 `ps -aux |grep ^foo |tr -s " " |cut -d " " -f2`
Løsningen som er gitt i Linux Gazette er den mest universale, men ikke den enkleste. Med både LILO og loadlin kan man bruke boot parameteret "single" for å boote direkte inn i et shell uten brukernavn/passord. Herifra kan man forandre på eller fjerne passord før en "init 3" for å starte flerbrukermodus. Number of reboots: 1 Andre veien: Number of reboots: 2
Justin Dossey
paul@geeky1.ebtech.net
Vi begynner med en "rå" og ren kildekode. Først: Skaff deg sendmail kildekoden. Jeg har versjon 8.9.0 av sendmail. Den lastet jeg ned fra ftp.sendmail.org:/pub/sendmail/sendmail.8.9.0.tar.gz
Filen er på omtrent 1MB, og når man tenker på at jeg kjører 8.7.6, er det nok verdt bryet. Hvis dette fungerer, vil du uten tvil høre om det, for ellers hadde jeg ikke kunnet sendt disse nye HOWTO versjonene uten e-post.:)
Nå som du har skaffet kildekoden, pakk den opp. Det vil da lages en katalog
kalt sendmail-8.9.0 i katalogen du er i. Gå inn i katalogen og les
README og RELEASE_NOTES filene (og bli forbløffet over alle oppdateringene
de har gjort). Nå, gå inn i src katalogen. Det er der mesteparten av
arbeidet ditt vil finne sted.
Anmerkning: Sendmail er et lite, kraftfullt og bra skrevet program. Binærfilen til sendmail ble kompilert på under 5 minutter på min 5x86 133 med 32MB RAM! Hele kompilasjonen og installeringen tok under 15 minutter!
Jeg kjører vanligvis ikke BIND på systemet mitt, så jeg fant disse linjene:
# ifndef NAMED_BIND
# define NAMED_BIND 1 /* bruk Berkeley Internet Domain Server */
# endif
i den forandret jeg 1 til 0, ala:
# ifndef NAMED_BIND
# define NAMED_BIND 0 /* ikke bruk Berkeley Internet Domain Server */
# endif
På Debian 1.3.1 er db.h å finne i /usr/include/db istedet for /usr/include hvor sendmail prøver å finne den. Gå inn i src, mailstats, makemap, praliases, rmail og smrsh katalogene og kjør denne kommandoen:
./Build -I/usr/include/db
Så snart du har gjort dette, cd .. og skriv make install. Der! Sendmail versjon 8.9.0 skal nå være installert! Det er selvsagt antatt at du allerede har din gamle konfigurasjon. For at alt skal virke perfekt, og siden jeg tilbyr gratise 'mailinglister' for folk som bruker majordomo, la jeg til den følgende linjen på begynnelsen av /etc/sendmail.cf:
O DontBlameSendmail=forwardfileinunsafedirpath, forwardfileinunsafedirpathsafe
Sendmail 8.9.0 er litt perfeksjonistisk når det gjelder kataloger og filadgangsattributter og det vil klage hvis kataloger og filer i aliases eller .forward filer er gruppeskrivbare eller 'skrivbare' av alle brukere (altså 'world writeable'). Det er ikke en gode ide å fjerne denne perfeksjonismen fra sendmail. Jeg kjører maskinen med bare en console bruker og jeg syntes det var OK å tillate dette lille sikkerhetshullet. YMMV.
jadestar@rahul.net
Lag og vedlikehold en /README.`hostname` og/eller en /etc/README.`hostname` [Eller f.eks /usr/local/etc/README.`hostname` -Maint. ]
Fra dag en som ansvarlig for et system sjekk loggfilene som ligger på maskinen. Du kan ta en: "vi /README.$(hostname)" en linje i root's /bash_logout. En annen måte å gjøre dette på er å skrive et su eller et sudo skript som gjør dette:
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 -
(bruk typescript for å ta en logg over dette og lag en funksjon som sørger for automatisk oppdatering og fornyelse av loggen.)
Jeg må innrømme at jeg har ikke implementert denne automatiseringen -- Jeg har bare stolt på selvdisiplinen til nå. Jeg har likevel lekt meg med ideen (har tilogmed laget prototyper av skriptene og shell funksjoner slik du kan se). En ting som holder meg tilbake er selve 'script' kommandoen. Jeg tror jeg blir nødt til å hente kildekoden og putte på noen flere kommandolinje parametre (for å pause/ stoppe skriptet fra kommandolinjen).
Mitt siste forslag for nå:
PATH variablen til root bør bestå av ' /bin'
Det er alt. Ingenting annet i root's path. Alt root gjør er sørget for av en symlink fra /bin, en alias eller en shell funksjon. Ellers kan det ligge skript eller binærfiler i /bin, eller root kan skrive inn filnavnet med programmets *hele* path.
Dette sørger for at de som kjører som root blir klar over hvordan han eller hun stoler på binærfiler. En smart system- ansvarlig vil fra tid til annen se gjennom /bin og /.*history filer for å se etter diverse 'hull' og mønstre.
Den *virkelig* motiverte ansvarlige vil stadig være på jakt etter sekvenser som kan bli automatisert. Steder hvor sunn fornuft kan bli brukt og oppgaver hvor root privilegier burde bli midlertidig fratatt (kjøre skriveprogrammer, MTA'er og andre store interaktive programmer med detaljerte skript-funksjoner som *kan* bli integrerte i transparente eller data filer -- som f.eks den lite berømte vi ./.exrc og emacs ./.emacs, den enda mer lumske $EXINIT og de integrerte 'header/footer' makroene). Naturligvis kan slike kommandoer bli kjørt slik:
cp $data $some_users_home/tmp
su -c $origcommand $whatever_switches
cp $some_users_home/tmp $data
Disse siste forsiktighetsreglene er litt i det meste laget for de vanlige "enbruker" arbeidsstasjoner -- Men de er veldig gode regler for den som er ansvarlig for et flerbrukersystem -- spesielt når det gjelder et system som er utsatt fra offentlige (spesielt utsatte) system (slik som Netcom sine).
a.triulzi@ic.ac.uk
/usr/bin/X11/xdm
exec /usr/bin/X11/X -indirect hostname
Jeg forteller dette fordi da jeg en gang prøvde desperat å sette dette opp for subnettet mitt, tok det meg over en uke for å ordne opp i alle problemene.
Anmerkning: med den gamle SLS (1.1.1) kan du legge til en -nodaemon etter xdm kommandoen -- dette virker derimot IKKE i senere utgaver.