Dela med dig av dina misstag, "*nix edition"

Jag har kommit undan rätt bra faktiskt. Har råkat genomföra en rm -rf * när jag stod i hemkatalogen på en server här hemma. Som tur var nyttjades den inte särskilt mycket, så det var ingen större förlust. Även nyligen satt upp en server som utsattes för intrång och nyttjades för att samla bitcoins (sårbarhet/okunskap om elasticsearch). Får också ses som ett stort misstag.

rm -rf * i fel mapp, istället för att ta bort lite skräpfiler försvann hela min Minecraftserver, visst fanns det ju lite backuper men inte för alla filer...

Lärdom: Gör inte saker på servern när man är för trött för att se vad som står på skärmen

Mycket intressant tråd då man lär sig en hel del måste jag säga

Genom åren har det givetvis blivit en del misstag, som att förstöra apt så jag inte ens lyckades återställa det, borttagning av fel filer (alltid lyckats återställa det som tur är), starta om service utan att spara konfigurationen (i LIO target så måste man aktivt välja att konfigurationen ska sparas om det sker via det interaktiva interfacet), glömt att spara program som jag efter många om och men lyckats kompilera (obskyra ting som jag ej kunnat hitta i repon eller färdigkompilerade). Uppgradering av VirtualBox på FreeBSD via ports har jag också utfört en gång när mina maskiner var igång, det var uppenbarligen inte omtyckt av dem då de gick ned (jag uppgraderade genom att manuellt uppgradera varje bibliotek via ports istället för att använda t.ex. portmaster, så något gjorde jag visst fel).

Via jobbet har jag suttit en del i HP-UX och där har det givetvis hänt att man gjort misstag, så som att radera innehållet i /stand (innehåller bland annat kernel) samt synka konfiguration mellan noder åt fel håll (synkat från A->B när jag skulle från B->A) vilket resulterade i borttappande av konfiguration. Det sistnämda hände för mig i en testmiljö som tur var, men har tyvärr inträffat för kollegor ute hos kund där systemet måste upp några minuter senare och aktuell backup saknats (detta görs under uppgraderingar och backup tas först när det visat sig fungera).

Fredagen den trettonde för några år sedan så lyckades jag ta bort mig själv ifrån sudogruppen i Ubuntu. Tänkte att det det bara var att boota i "single user mode" för att lösa det. Tyvärr kunde jag inte få få fram grubmenyn visade sig vara en bugg i min Ubuntuversion och kunde inte lösa det eftersom jag inte var root. Dröjde en vecka tills jag kom hem och kunde boota upp med en livecd och fixa det.

Ett annat misstag jag gjort några gånger är att man väljer fel ssh fönster och lyckas installera paket på en annan server än det var tänkt. Brukar gå att lösa ganska snabbt men är alltid frustrerande när det händer.

Jo, jag utvecklade i ett senare inlägg. Just i detta fallet så kanske du skulle ta bort just en Git-katalog, det vet jag inget om; jag funderade mest på en uppfattad allmän tendens att använda `-f` då jag åtminstone fått för mig att jag ser det ofta i enkla kodexempel när jag själv bara behöver det i rätt speciella fall.

I hemkatalogen på hemsystemet så hittade jag bara Git- och SVN-filer som var skrivskyddade för ägaren. I `/etc` hittade jag tre filer. I `/usr` var det bara delar av Matlab- och VMware-installationerna som var satta u-w av oklar anledning, tre CUPS-filer samt en fil i Javainstallationen. Att det är så få filer gör i praktiken att det oftast inte spelar in alls. Dock så gör ju `-f` också att `rm` ger lyckad status och inget felmeddelande ifall filen/katalogen man försökte ta bort inte fanns, vilket troligen är oönskat på kommandoraden (men praktiskt i exempelvis makefiler).

Letar sådana filer med Git- och SVN-kataloger exkluderade med exempelvis:

sudo find /usr \( -path '*/.git/*' -o -path '*/.svn/*' \) -prune -o -not -perm /u+w -a -print

Ja, PhotoRec verkar jobba genom att identifiera karakteristiska inledande och avslutande bitar och var nog det bästa att hoppas på. Det verkar också vara bra mycket smartare än en manuell `grep`-metod genom att analysera bitar för att eventuellt kunna återskapa även fragmenterade filer. Lite extra drygt då att programmet lyckades hitta bilder, men bara en massa skräp .

cd /
rm -rf <prefix> *

Notera mellanslaget mellan <prefix> *

Detta var på en prodserver på ett av sveriges större företag. Jag insåg mitt misstag när sekunderna tickade och kommandot inte körts klart...

Att testa en dist med systemd. Lennart Poettering och Kay Sievers har förstört linux. Det känns bra att Linus har börjat inse det med.

Jag är själv lite splittrad i den här frågan.
Jag älskar systemd för dess otroliga smidighet och möjligheter... massor av möjligheter.... men...
Jag hatar systemd för dess otroligt ofantliga onödiga komplexitet. Ett praktexempel på hur långt ifrån KISS-principen man kan gå.

... ja... jag både älskar och hatar systemd...

Jag har lyckats fler än en gång formatera fel hårddisk/partition, bland annat boot, home m.fl. Senaste gången va då när jag skulle installera Arch Linux från Linux Mint (tror jag), hade då en 80 GB's HDD som backup för configs och liknande. Gissa vad man lyckades med rakt in i installationen i Arch? Jo, skulle flytta över all backup men råkade istället formatera fel partition... Det blev att ominstallera hela skiten alltså. Jätteglad man var då )))

För en "normal" användare behöver man sällan eller aldrig bry sig om systemhanteraren. När man installerat det man behöver är man nöjd.
Men när något strular, och man behöver administrera sitt system, så blir situationen lite annorlunda.

För det första så började många populära distributioner ersätta det gamla "init / sysv" med "systemd" innan dokumentationen var färdig.
(Nu finns det lite varianter på de gamla init-systemet, men det är inget jag går närmare in på här, utan jag tar helt enkelt och kallar dem alla för "init" för enkelhetens skull.)
Den, då, bristfälliga dokumentationen (Det har blivit bättre) resulterade i att distributionerna implementerade lite egna lösningar på de ställen som dokumentationen var bristande/obefintlig i. Alternativt saknades vissa viktiga funktioner. När de lite mer tekniska användarna, däribland jag själv, skulle försöka kringgå "barnsjukdomarna", så gick man på den ena minan efter den andra. Det slutade med att man började introducera diverse ful-lösningar på annars banala problem. Hade bara dokumentationen funnits där vore det en annan femma.

Okej, nu klagar jag mer på dokumentationen, än på systemd i sig. Men skillnaden mellan det gamla, och det nya vara att med "init", var många delar rätt självklara så fort man tittade i konfigurationsfilerna och i scripten. Man fick en "Aha!" upplevelse. Så var/är inte fallet med systemd. Visst, studerade man bara scripten tillräckligt noga och tillräckligt djupgående, så förstod man. Men det var inte alls lika "KISS" över det hela.

Men jag själv, som en del andra, kom att börja förstå djupet, och därmed smidigheten i systemd. Den löser faktiskt en del problem som det gamla init har dragits med en bra tid. Som dessutom var svåra att lösa med befintlig struktur. Vissa försök gjorde, och lyckades väl sådär halvdant. En av de mer märkbara "problemen" var parallell uppstart. Vissa lösningar introducerades, men de var inte fullt så effektiva, och kunde även i vissa konfigurationer ställa till med problem. Systemd råder bl.a. bot på detta problem, och är från grunden skapat för just parallell uppstart, och snabbar upp systemstarten avsevärt mycket. Även på SSD-system.

Sedan finns det en del andra rätt så snaskiga förbättringar som kommer med systemd, men jag tror att jag får stoppa här, för nu känns det som om jag håller på att dra iväg med tråden långt utanför sitt spår.
Där har du min hat-kärlek till systemd.

i min ungdom var jag rebellisk och skulle installera linux. så jag googlade efter vilken linux som var bäst, och installerade gentoo. skiten tog 3 dagar att kompilera på min ibm x60...

Nyligen tog jag bort en ZIL från en ZFS-pool som hade stått i över 7 timmar på resilvering. Resultatet blev att den började om igen..

(Anledningen till att jag tog bort ZILen var för att SSDn som agerade ZIL började rapportera skrivfel.)

Skulle ghosta en klientdator på jobbet och hade en USB-sticka som boot och en extern HD med alla images på. Hade funkat fint förut men denna gång valde jag fel. Klientdatorns och den externa HD:n var lika stora. 500 GB och jag valde i all hast fel och nitade alla 20+ images på den externa HDn. Det blev merjobb som hette duga. Nu kör vi netboot bara så problemet är ur världen.

crontab -r istället för crontab -e är ju en klassiker. Helt perfekt att e och r är bredvid varandra... Annars gjorde jag en rm .* istället för rm .*~ nån gång (även detta pga tangentbordslayoutens beskaffenhet), men det är väl det man har backuper till...

Ett annat misstag jag "råkade" ut för:

Arch Linux, som jag använder flitigt, är en så kallad "Rolling release" distribution. Det betyder att distributionen uppdateras kontinuerligt hela tiden, istället för att släppa separata distributionsversioner likt Ubuntu 12.04, 12.10, 13.04 ...
Med detta följer större ändringar med jämna mellanrum, och är man inte med på noterna kan det bli en överraskning för en. Positiv eller negativ beror helt på hur förberedd man är.

Upptakten:
För ett tag sedan bestämde sig Arch-utvecklarna att det var dags att ta tag i de utspridda bin-mapparna, och slå samman dessa.
Detta kom att innebära vissa problem med redan existerande system som uppdaterade till den nya bin-strukturen. Det krävde att man förberedde systemet INNAN uppdatering.
Hur kunde man veta att man skulle förbereda systemet i förväg? Enkelt: Man skall ALLTID läsa nyheterna på Arch hemsida, innan man uppdaterar. Där framgår vad som för stora förändringar man skall förbereda sig för, och preparera inför.
Att bara uppdatera systemet i blindo utan att först läsa nyheterna är något man absolut inte skall göra om man inte vill ha problem.

Mitt misstag:
Jag läste inte på nyheterna i tid, och valde att leva farligt. -"Äch vafan, det brukar ju aldrig vara några större förändringar att bry sig om i alla fall".
Jotack. Det fick man käka upp senare.
Uppdaterade i blindo, och helt plötsligt tar det tvärstopp med saknade binärfiler, kommandon som inte fungerar, och tjänster som vägrar starta.
Att fixa till detta i efterhand är mer besvärligt än det hade varit att förbereda systemet innan.
Ja... där har man för att man skiter i nyheterna och struntar i dokumentationen. Jag var lite för självsäker med mig själv där helt enkelt.

Tog mig några timmar att få allt i ordning igen.

Lär er av mitt misstag: Läs nyheterna till er distribution. I synnerhet om det är en rolling release-distribution.
Det är bättre att ha läst ett stycke för mycket, än ett för lite.