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
> > Vilka är för- och nackdelarna med att göra detta?
Fördelar: du spar en hel del hårddiskutrymme.
Nackdelar: om steg 5 inte sker automatiskt så måste du komma ihåg att göra det för hand och dessutom gör det ombootningsprocessen en nanosekunde långsammare. :-)
michael@actrix.gen.nz
Här kommer ett trick som jag varit tvungen att använda ett par gånger.
Desperata människors textfils-undelete.
Om du av misstag raderar en textfil, t.ex. e-post eller resultatet av en sen natts programmeringssession, så behöver inte allt vara förlorat. Om filen någonsin sparades på disk, alltså om den existerade i åtminstone 30 skunder, så kan dess innehåll fortfarande finnas kvar på partitionen.
Du kan använda kommandot grep för att leta igenom den råa partitionen efter innehållet i filen.
Nyligen tog jag t.ex. bort ett e-brev. Jag avslutade omedelbart all aktivitet som kunde modifiera den partitionen: i detta fall lät jag bara bli att spara filer och kompilera osv. I andra fall har jag faktiskt gått igenom de besvär det innebär att ta ner systemet till enanvändarläge (single user mode) och avmonterat filsystemet.
Sen använde jag kommandot egrep på partitionen: i mitt fall fanns e-brevet i /usr/local/home/michael/, så från utdatan från df kunde jag sluta mig till att det fanns på /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
Sedan använde jag strings för att hjälpa mig med att inspektera utdatan:
strings /tmp/x | less
Den här metoden är inte att lita på, allt eller en del av diskutrymmet kan redan ha blivit återanvänt.
Detta trick är antagligen bara användbart på ett enanvändarsystem. På system med flera användare och med mycket diskaktivitet så kan utrymmet du har frigjort mycket väl redan ha återanvänts. Och de flesta av oss kan inte bara ta ned maskinen för våra användare när vi måste hitta en fil vi tagit bort.
På det system jag kör hemma har detta trick varit användbart vid ungefär tre gånger under de senaste åren - vanligtvis när jag förstör en del av dagens arbetsresultat. Om det jag gjort klarar sig så långt att jag tycker att jag gjort anmärkningsvärda framsteg så brukar jag säkerhetskopiera det på disketter, så jag behöver inte använda detta trick så ofta.
jadestar@rahul.net
Använda immutable-flaggan
Så fort du har installerat och konfigurerat ditt system så bör du gå igenom /bin, /sbin, /usr/bin, /usr/sbin och /usr/lib (och några av de andra katalogerna) och på ett sparsamt sätt använda 'chattr +i kommando'. Lägg också till det till kärnfilerna i rotkatalogen. Kör nu 'mkdir /etc/.dist' och kopiera allt från /etc/ dit (själv gör jag detta i två steg, med /tmp/etcdist.tar för att undvika rekursion). (Du kan även bara skapa /etc/.dist.tar.gz - och göra den immutable.)
Anledningen till allt detta är att beränsa skadan du kan göra när du är inloggad som root. Du kan inte skriva över filer av misstag och du kan inte göra systemet oanvändbart med ett mellanslag för mycket om du använder 'rm -rf' (du kan fortfarande förstöra en massa data - men dina bibliotek och binärfiler är säkrare).
Detta gör också en hel del intrång och "denial of service"-angrepp antingen omöjliga eller svårare (eftersom många av dem är beroende av att kunna skriva över någon fil genom ingrepp av något SUIDat program som *inte tillhandahåller ett visst skalkommando*).
Det enda otrevliga med detta är att när du kompilerar och kör 'make install' på olika typer av systembinärfiler. Å andra sidan så hindrar det också 'make install' från att skriva över filerna. När du glömmer att läsa Makefilen och chattr -i filen som ska skrivas över (och katalogerna till vilka du ska lägga till filer) så misslyckas make-kommandot, men då är det bara att använda kommandot chattr och köra det igen. Du kan också ta tillfället i akt och flytta dina gamla binärfiler, bibliotek och vad som helst till en .old/-katalog, eller byta namn på dem eller tar-a dem eller vad som helst.
jadestar@rahul.net
Alla nya saker ska in i /usr/local eller /usr/local/'hostname'!
Om din distribution är en som lämnar /usr/local tomt, så skapa bara din /usr/local/src, /usr/local/bin osv. och använd dem. Om din distribution stoppar saker i /usr/local-trädet så är det kanske bäst att köra 'mkdir /usr/local/`hostname`' och ge 'wheel'-gruppen +w till den (jag gör den också SUID och SGID för att se till att varje medlem i wheel-gruppen bara kan greja med sina egna filer där och att alla filer som skapas tillhör wheel-gruppen).
Se nu till att vara disciplinerad och *ALLTID! ALLTID! ALLTID!* stoppa nya paket i /usr/local/src/.från/$VAR_JAG_FICK_DET_IFRÅN/ (för .tar eller vilken fil det nu var) och kompilera dem under /usr/local/src (eller .../$HOSTNAME/src). Se till att det installeras under local-trädet. Om det *absolut måste* installeras i /bin eller /usr/bin eller någon annanstans, så kan du skapa en länk från local-trädet till varje element som finns någon annanstans.
Anledningen till detta, även om det leder till mer jobb, är att det hjälper till att isolera det som ska säkerhetskopieras och återställas från distributions-mediet (nu för tiden är det oftast en CD). Genom att använda en /usr/local/.from-katalog upprätthåller du också en informell logg om varifrån källkoden kommit, vilket hjälper dig då letar efter nya versioner, och hjälper dig då du läser igenom säkerhetsmeddelandena i announcement-listor.
Ett av de system jag har hemma (det jag skriver detta på) sattes upp innan jag själv började arbeta enligt dessa principer. Jag "vet" fortfarande inte precis hur det skiljer sig från ett system från en "ren installering". Detta trots att jag har gjort väldigt lite med det systemet, inte konfigurerat det speciellt mycket och är den enda som använder det.
I kontrast till detta så har de system som jag satt upp på jobbet (sedan jag kastats in i rollen som systemadministratör) blivit konfigurerade på detta sätt - de har administrerats av många människor och MIS-typer och har gått igenom många stor uppgraderingar och paketinstalleringar. Trots detta har jag en klar uppfattning om vilka exakta element som lags in *efter* den ursprungliga installeringen och konfigureringen.
dossey@ou.edu
Jag la märke till några överdrivet svåra eller onödiga procedurer som rekommenderades i avdelningen med 2c-tips i nummer 12. Eftersom det är mer än ett, så skickar jag dem till dig:
#!/bin/sh
# lowerit
# konvertera alla filnamn i den aktuella katalogen till små
# bokstäver. påverkar bara vanliga filer - ändrar inte namnen
# kataloger. frågar om lov innan det skriver över 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;
Bidragsgivaren säger att han skrev skalprogrammet såsom han gjorde det för att det skulle bli lättare att förstå (se nedan).
I nästa tips, som handlar om att lägga till och ta bort användare, så gör Geoff allt rätt ända tills han kommer till sista steget. Boota om? Gosse, jag hoppas att han inte bootar om varenda gång han tar bort en användare. Allt du behöver göra är att utföra de två första stegen. Vilket slags processer kan den användaren ha igång, förresten? En irc-bot? Döda processerna med ett enkelt
kill -9 `ps -aux |grep ^<username> |tr -s " " |cut -d " " -f2`
kill -9 `ps -aux |grep ^foo |tr -s " " |cut -d " " -f2`
Lösningen som gavs i Gazetten är den mest använda, men inte den enklaste. Till både LILO och loadlin kan man skicka med parametern "single" för att boota direkt till standardskalet utan behöva skriva användarnamn eller lösenord. Därifrån kan man ändra eller ta bort vilket lösenord som helst, innan man skriver "init 3" för att köra igång fleranvändarläget.
Antal ombootningar: 1 Det andra sättet Antal ombootningar: 2
Justin Dossey
jadestar@rahul.net
Skapa och upprätthåll en /README.`hostname` och/eller en /etc/README.`hostname`. (Eller kanske /usr/local/etc/README.`hostname` - Ansvarige.)
Från och med *dag ett* ska du absolut föra anteckningar i en loggfil. Du kan lägga in en rad med "vi /README.$dollar;(hostname)" i roots /bash_logout. Ett annat sätt är att skriva ett su- eller sudo-skalprogram som gör något i stil med följande:
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 -
(använd typescript-kommandot för att skapa en sessionlogg och skapa en funktion för att automatisera tilläggen och uppdateringarna av loggen.)
Jag ska erkänna att jag inte har lagt in denna automatisering av princip - jag har hittills bara litat på självdisciplin. Jag har dock lekt med idén (till och med gått så långt som till att göra prototyper för skalprogrammen och skalfunktionerna som du ser dem i det här dokumentet). En sak som hindrar mig från att genomföra detta är script-kommandot självt. Jag tror jag kommer bli tvungen att plocka hem källkoden och lägga till några kommandoradsparametrar (för att pause/stoppa skalprogrammets "inspelning" av kommandoraden) innan jag börjar använda det.
Mitt sista förslag (för denna gång):
Roots sökväg ska bestå av 'PATH= /bin'.
Det är allt. Inget annat ska finnas i roots sökväg. Allt root gör ska finnas som en länk från /bin eller genom ett alias eller en skalfunktion, eller som ett skalprogram eller binärfil i /bin, eller ska skrivas in med den fulla sökvägen.
Detta gör alla som kör som root (ibland smärtsamt) medvetna om vilket förtroende han eller hon har för binärfiler. Den vise systemadministratören i ett fleranvändarsystem kollar då och då igenom sina /bin- och /.*history-filer efter mönster eller kryphål.
Den verkligt motiverade administratören kommer lägga märke till sekvenser som kan automatiseras, ställen där förnuftskollar kan läggas in och uppgifter för vilka "root"-privilegierna tillfälligt kan upphävas (köra igång editorer, MTAn och andra stora interaktiva program med goda inställningsmöjligheter som *kan* läggas in transparent eller i datafiler - som den kända ./.exrc för vi och emacs ./.emacs och det änn mer välkända $EXINIT och de inbäddade header/footer-makrona). De kommandona kan naturligtvis köras med något i stil med:
cp $data $någon_användares_hem/tmp
su -c $origkommando $diverse_argument
cp $någon_användares_hem/tmp $data
Den sista sortens förbehåll är överdrivna om det handlar om en ensam användares arbetsstation - men de är väldigt bra av princip, om du är administratör av ett fleranvändarsystem - speciellt ett allmänt exponerat system (som de på netcom).
a.triulzi@ic.ac.uk
/usr/bin/X11/xdm
exec /usr/bin/X11/X -indirect hostname
Jag lägger till detta eftersom det, när jag desperat försökte konfigurera det för mitt eget subnät, tog mig ungefär en vecka att reda ut alla problemen.
Varning: med gamla SLS (1.1.1) kan du av någon anledning lämna ett -nodaemon efter xdm-raden - detta fungerar INTE med senare utgåvor.