Linux langsiktige stabilitet innebærer at brukerne kan gå i årevis bare oppgradere pakker uten noen gang å gjøre en re-installere fra scratch. Tro det eller ei, det er ikke alltid en god ting. Det er anbefalt praksis for servere, naturligvis, men en merkelig bivirkning er at når du ikke
slutt re-installere (en stasjonær eller en server), har du alderen gamle tilpasninger og tilpasninger bygget opp, og gjengi dem kan være en forvirrende problemfri. Jeg har nylig foretok en fra-scratch-reinstallering, så noen av de erfaringene jeg har lært kan være verdifull når du takle din neste migrasjon.

For å være presis, begynte jeg opplever harddisk problemer på en av mine stasjonære maskiner ( med disken der min root partisjon levde), og å se skriften på veggen, bestemte jeg meg for å erstatte den aldrende disk. En ny utgave av at maskinens distro hadde nettopp droppet (Ubuntu), så en fersk installasjon var ikke mye verre enn en oppgradering pluss migrere til en ny disk. Jeg tok også muligheten til å installere /
til en SSD, som ikke påvirker prosessen mye, og til slutt flytte den maskinen fra 32-bit til 64-bit build, som gjør Anmeldelser påvirke prosessen. Det betyr at jeg kan ikke bare kopiere binærfiler fra en maskin til en annen; i stedet jeg må faktisk sortere ut hva som er installert på den gamle maskinen, og gjenskape det

Fra fugleperspektiv, migrere innstillinger og ". tilstedeværelses " til en helt ny maskin betyr å ta lager av alt lokalt installert og tilpasset på systemnivå (nemlig programpakker), bestemme aksjepakke-set du trenger for å gjenskape på den nye maskinen, isolere noen spesielle programmer som databaser, og bevare din konfigurasjon og innstillinger (system-wide og personlig). Selvfølgelig må du migrere selve filene, også, men det er neppe et uløst problem. For øyeblikket vil vi bare holde oss til programvare og ikke-datadelene til OS.

Støtt din /local /Hierarki

Det første du må gjøre er å ta opptelling av alle pakkene på din gamle maskin som du kan ikke bare re-installere gjennom den nye maskinen sitt pakketjeneste. For det første, dette inkluderer alt som du har kompilert og installert lokalt. Ifølge mappehierarkiet standard (FHS), tilhører lokalt installert programvare i /usr /local /bin /og (for systemadministrasjonsprogrammer, /usr /local /sbin /). Du kan ta lager av innholdet i disse katalogene for å sikre at du ikke glemmer noe, men hvis du bygget RPM eller Debian-pakker fra kilde snarere enn å installere programmene med make install, kan pakkene bli installert i normal /usr /bin /og /usr /sbin /kataloger i stedet.

I så fall må du slå til pakkebehandleren for å få hjelp. Apt front-ender som Synaptic kan vise deg lokalt installerte pakker til Debian-baserte systemer (inkludert Ubuntu og alle dets derivater). Så vidt jeg kan fortelle, ikke nam ennå ikke gjennomføre en lignende funksjon for RPM-baserte distribusjoner, selv om det har vært diskutert

Du kan fange opp tilsvarende informasjon med en bit av albuen fett, men:. På YUM listen, foreslår Tom Mitchell kjører rpm -qia og leter etter den " Bygg Host " felt - et lokalt sammensatt pakke bør ha den lokale maskinens vertsnavn. Mitchell foreslo rykende utgang til mindre
, men rpm -qia | grep -B 3 ' yourhostname
' | mindre vil finne bare de pakkene som svarer til ditt lokale maskin navn. Forhåpentligvis du har plukket en uvanlig en

Til slutt bør du alltid være på vakt mot uhell med utsikt proprietære applikasjoner -. Særlig når de kommer i installasjonen skallskript i stedet for standardpakker. Uavhengige programvareleverandører har en tendens til å slippe binærfiler og konfigurasjoner i særegne steder. Mange går i /opt /, men det er ingen idiotsikker måte å finne dem alle. Du kan enten bruke rpm-QF /noen /bestemt /banenavnet eller dpkg -S /noen /fil /navn for å finne ut hva (hvis noen) pakke en mistenkelig utseende filen tilhører, men du er like sannsynlig å være vellykket ved lesing gjennom " Programmer " systemmenyen og taxing hukommelsen.

Manifest Destiny

Neste opp, vil du ønsker å generere en liste over installerte pakker på ditt gamle systemet, som du kan bruke for å gjenskape den installerte-pakken -liste på den nye maskinen. Dette er en litt lettere på Debian-baserte systemer, fordi dpkg har en innebygd kommando for formålet, men det er lett nok på RPM distroer også.

På en Debian-system, kjøre dpkg --get -selections > my-programvare-packages.txt. Dette vil skrive en liste over alle installerte pakker på ditt system til min-programvare-packages.txt fil. For all del alle
; ikke bare de pakkene du valgte, men alle bibliotekene, datapakker og andre avhengigheter at de trekker i tillegg. Det vil være en lang liste

Du kan redigere den for hånd og fjerne ting du ikke bryr deg om, men vær forsiktig så du ikke å slette en linje, men la en avhengig pakke i andre steder i filen.; det ville være en konflikt. Det er også opp til deg hva du skal gjøre om de lokalt installerte Debian pakker (hvis noen) diskutert i forrige avsnitt. Den enkle løsningen kan være å avinstallere dem før du genererer filen, men det gjør livet vanskeligere hvis migrasjon tar lengre tid enn du forventer. Excising linjene i spørsmålet fra en teksteditor er trolig like enkelt; folk flest ikke har mer enn en håndfull lokale pakker

På den nye maskinen, du kan flagge den fullstendige listen over pakker ved å kjøre dpkg --set-valg <.; my-programvare-packages.txt - kjør dselect å starte installasjonen, og nyte en god bok mens prosessen spyr

RPM distro brukere kan generere en omfattende pakke liste med rpm-qa >. my-programvare-packages.txt. Du må også vurdere polering opp på listen før du mater den inn den nye maskinen pakken manager; alle de samme begrensningene gjelder. Når du er fornøyd, men kjøre yum -y installere $ (katten min-programvare-packages.txt) på den nye maskinen. Nyt en like god bok

Filer du faktisk ønsker

Jeg sa i innledningen at jeg ikke kom til å ta opp migrere datafiler, siden det er på noen måter en enklere prosess &mdash.; og fordi to brukerne har de samme dataene, er det vanskeligere å generalisere. Men det er noen systemomfattende
filene du trenger for å lage spesielle bestemmelser for, for eksempel innhold i /var /og konfigurasjonsfiler i /etc /.

Noen av disse filene vil potensielt være annerledes nok på den nye maskinen som du vil definitivt ikke
ønsker å bare kopiere over den gamle filen inn i den nye /etc /katalog. For eksempel /etc/modprobe.d, eller /etc /fstab og /etc/mdadm.conf. På den annen side, kan det være lurt å bevare noen lokalt finslipt konfigurasjoner, som for eksempel eventuelle tilpassede cron oppføringer i /etc/cron.d/, LAN hostname informasjon i /etc /hosts, nettverkskonfigurasjon i /etc /network /eller noen brannmur konfigurasjonen du kanskje har lagret (for eksempel i /etc/iptables.rules).

Den vanskelige delen er at Linux gjør for så mye fleksibilitet i navngiving og plasseringen av disse konfigurasjonsfiler som det er vanskelig å skrive generelle regler. For eksempel, du kan
lagre brannmurregler i /etc/iptables.rules, men du kan like gjerne holde dem i /etc/network/if-pre-up.d/iptablesload. Hvis du ikke er sikker på om historien til dine tilpasninger, er det trygt leke å lage en kopi av din /etc /katalog i et annet sted på den nye maskinen, og løse forskjeller, ett om gangen. I fremtiden kan du vurdere en konfigurasjon-versjon-kontrollsystem som etckeeper for den nye maskinen, slik at neste migrasjon vil bli bedre dokumentert.

/var /katalog er like inkonsekvent. Mange spill pakker bruke /var /spill /lagre innstillinger og data som må være synlig for flere brukere – glem å migrere det, og det verste som kan skje er at du mister alle rekordene dine. På den annen side, /var /www /er historisk hvor web-applikasjoner er installert, og du sannsynligvis ikke ønsker å flytte til en ny maskin uten dem. Det kan være lurt å re-installere lokale web-verktøy på den nye maskinen hvis du gjør en oppgradering på samme tid - det avhenger av om nye versjoner av skript motorer og biblioteker som brukes kommer med oppgraderingen. Selv om du ikke gjør det, men du sannsynligvis trenger å bevare dataene i web apps.

I alle fall er dette et annet emne, hvor du er nødt til å tenke ut en strategi fra sak til sak . Enkle web-verktøy som CUPS-front-end eller phpMyAdmin du bør ikke ha problemer å installere på den nye maskinen. En web-basert regnskap pakke som du bruker hver dag, men må behandles forsiktig for å unngå tap av data.

Alle dine data er tilhører Base

Lokal webinnhold fører til et annet viktig Subject: databaser. Migrere databaser fra en maskin til en annen krever vurdering av databasesystemet brukes, lagringsformat, og arkitekturer involvert. Som med /var /www /, er det et viktig skille mellom programmer der du vil
å starte på nytt på den nye maskinen fordi konteksten er annerledes (for eksempel Webmin) og programmer der du trenger å migrere data (for eksempel et GIS app).

Heldigvis oppstår behovet ofte nok at mye av RDBMS-støttede programmer vil bundle sine egne databasemigreringsverktøy, akkurat som de gjør backup verktøy. MythTV, for eksempel, inneholder sikkerhetskopiering og gjenoppretting skript som kan brukes til å migrere fra en maskin til en annen uten tap i tjenesten.

Andre apps kanskje ikke være så gavmilde, i så fall bør du starte med å rådføre deg database dokumentasjon. MySQL har omfattende online docs dedikert til å migrere databaser mellom maskiner. Det er en god sjanse for at din gamle en ny stasjonære maskiner vil bruke samme binære lagringsformat (de fleste PC-arkitekturer gjør), i hvilket tilfelle Inngrepet er enkelt: du kan kopiere den underliggende .frm, .MYI, og .MYD filer fra en maskin til en annen -. forutsatt at du kopierer mysql
database selv, og gjenskape MySQL brukere til den nye maskinen

Selvfølgelig må du finne
kan de nevnte MySQL binærfiler før du kopierer dem. Hvis du trenger å finne deg, kjøre grep datadir /etc/my.cnf. Selv for svært store databaser, er dette direkte kopi metoden raskere enn den gammeldagse migrasjonsprosessen, der du dumpe databasen på den gamle maskinen, overføre dump til den nye maskinen, og importere den til en ny database. Hvis du tilfeldigvis bruke en merkelig, ikke-standard lagringsmotor, må du gjøre litt ekstra graving, men for de fleste brukere, er smertefri overføringsprosessen. Bare sørg for å kjøre noen tester på den nye maskinen før du sletter den gamle.

sveiper ut hjørnene

Det er sannsynlig å være særegenheter på alle systemer som ikke vil bli fanget av de generelle migrasjons hint, men hvis du har råd til å migrere til din nye maskin (eller rett og slett den nye root partisjon og filsystem), mens den gamle er rundt, kan du ta de fleste av dem i løpet av noen ukers tid løping det nye systemet. Denne listen kan inneholde lokalt installerte pakker som ikke inkluderer slippe noen kjør inn /usr /local /bin /og /usr /local /sbin /(for eksempel vindusbehandler eller ikon temaer), Java-programmer som endte opp i uvanlige kataloger, og programmer som bruker særegne steder å lagre sine data og innstillinger (for eksempel /usr /share /istedenfor /var /— det faktum at de bør ikke
garanterer ikke at de won 't
).

Naturligvis, selv etter at du klarer å gjenskape programvaremiljø og systemkonfigurasjon fra den gamle maskinen til den nye en, du har fortsatt å flytte dine personlige filer. Jeg har vært forutsatt så langt at dette innholdet er enten lagret på ett sted (innen /home /), eller annet på andre monteringspunkter som du kjenner godt nok til å re-feste ordentlig. Men når overføringen skjer også samtidig som en systemoppgradering (som mitt eksempel gjorde), kan du bare montere den gamle /home /på den nye maskinen introdusere sin egen andel av problemer på grunn av utdaterte og oppgraderte innstillingene i skrivebordsmiljøet og applikasjoner.

Derfor kan det være bedre å endre navn på gamle konfigurasjons mapper som .gconfd og .kde4 og bruke dem bare som referanse når tweaking det nye miljøet. Den gode nyheten er at eldre applikasjoner og lavere nivå verktøy er mer stabile enn skrivebordsmiljøer og langt mindre sannsynlighet for å innføre API endringer. Så pålitelige favoritter som .bashrc, .vimrc, .emacs.d /, og .ssh /er ansvarlig for å seile gjennom noen oppgraderingsprosessen, uansett hvor stikkende, og være venter på deg på den andre siden. Anmeldelser

Previous:Komme i gang med Embedded programmering i Linux, den billig og enkel Way

Next Page:UPnP med People: Open Source Media Sharing med MediaTomb