Wily Werewolf (15.10)

[Jimmyfj]

Code-Name Wily Werewolf, --> 15.10 - Er navnet på den næste udviklingsface over de kommende seks måneder.

Wily vil blive en overgang fra .deb pakkesystemet til Ubuntus egen snappy pakkesystem.

Her er det vigtigt at gøre opmærksom på, at selv om Ubuntu bevæger sig over på snappy, så kan .deb pakker stadig bruges også i 15.10 - Jeg tror vi skal længere frem inden tranformationen er gennemført hele vejen.

Wily vil også komme med Linux 4.0 kernen, hvor den største nyhed er live patching af kernen (opdatering/patchning) uden at genstart er nødvendig - Om en versions-opdatering også bliver uden genstart er jeg ikke helt klar over, men det kommer jo nok frem meget snart.

Du kan allerede nu rette din /etc/apt/sources.list til wily, men du skal ikke forvente, at der allerede ligger opdateringer.

Eneste opdatering jeg har fået er Ubuntu-Base 7.2.et-eller-andet. Ikke nogen mærkbar ændring.

Hopper du over på Wily Werewolf skal jeg, som vanligt, minde dig om, at vi i denne tråd arbejder med pre-alpha, alpha og beta-software, som, på ingen måde egner sig til produktionsmaskiner.

Det er udviklingsarbejde på højtryk, og fejl vil ske. Fejl, som potentielt kan efterlade dit system ubrugeligt, med gen-installation til følge.

Udviklerne opfordre, som altid, til at udviklingssoftwaren afprøves på så mange systemer, som muligt, for at få udryddet de værste fejl i dette forløb.

/Jimmy

[AJenbo]

Wily vil blive en overgang fra .deb pakkesystemet til Ubuntus egen snappy pakkesystem.

Det gør sig kun gældende for den eksperimentielle Ubuntu-next og ikke det der kommer til at blive Ubuntu 15.10 (Wily Werewolf), den vil fortsat være med .deb.

Wily vil også komme med Linux 4.0 kernen, hvor den største nyhed er live patching af kernen (opdatering/patchning) uden at genstart er nødvendig - Om en versions-opdatering også bliver uden genstart er jeg ikke helt klar over, men det kommer jo nok frem meget snart.

Det er kun bestemte rettelser det bliver muligt at live opdatere, og det kræver at Canonical laver lidt ekstra arbejde for at en opdatering kan gøre brug af det. Det gælder heller ikke resten af systemet som stadig kan kræve en genstart.

[Jimmyfj]

Hvis jeg forstår dig ret, så gælder "Live Patching" 'kun' sikkerhedsopdateringer, og andre, mindre opdateringer?

SUSE og Red Hat har hver deres tilgang til området:

kPatch is issuing stop_machine()”, inspecting processes and deciding whether the system is safe to patch; “kGraft provides a per-thread consistency during one single pass of a process through the kernel and performs a lazy contiguous migration of threads from 'unpatched' universe to the 'patched' one at safe checkpoints.”

De to metoder er nu 'smeltet' sammen til én:

http://www.infoworld.com/article/2862739/linux/the-winning-linux-kernel-live-patch-all-of-the-above.html

Som du kan se i artiklen anses 'live patching' stadig at være eksperimentel, omend i SUSE's tilfælde i brug i deres Enterprise udgave.

Hvor vidt Canonical kan gøre 'live patching' stabil nok i denne cyklus får vi at se.

Her er en review fra eweek:

http://www.eweek.com/enterprise-apps/linux-4.0-goes-live-with-live-kernel-patching.html

Det tegner til at blive en spændende cyklus med alle de nye tiltag omkring Linux 4.0.

[AJenbo]

Ja det er min forståelse af det. Det er noget med at det kun kan lade sig gøre at live-patche en funktion og ikke struktur mæssige ændringer i kernen. Det burde dog være nok i de fleste tilfælde hvor det handler om sikkerhedsopdateringer. Det ekstra arbejde det kræver at lave en live-patch vil nok også betyde at det kun er noget der bliver gjort for sikkerhedsopdateringer, og muligvis kun dem der påvirker servere (kun LTS?). Men vi må se hvad Canonical beslutter sig for.

[Jimmyfj]

Hvis Live Patching kun kommer til at gælde LTS kommer vi nok ikke til at se det implementeret før i 16.04.

Som jeg forstår det, opgraderer man ikke LTS udgavernes kerne bagudrettet, hvilket for 14.04 LTS vil være noget af en omvæltning, da den kører med kernel 3.14.x.

Mark Shuttleworth har allerede meldt ud, at Wily kommer med Linux 4.0 kernen - Tiden bil så vise, hvor meget live patching vi får. Men spændende bliver det.

[AJenbo]

LTS får ny kerne i takt med de normale udgivelser 14.04.2 har Linux 3.16, 14.04.03 kommer d. 6/8/2015 med 3.19, 14.04.4 vil så komme med en 4.x kerne. Disse opdaterede kerner vil dog også kun have 9 måneders leve tid lige som ved de normale udgaver. Kun den oprindelige kerne vil være understøttet i alle 5 år af 14.04s levetid.

Jeg vil næsten tro de opdatere til 4.1 eller 4.2 inden udgivelsen af 15.10, sådan plejer det at være.

[Jimmyfj]

Jeg har lige installeret Ubuntu Wily (a.k.a. 15.10) 28-5-15 daily build.

Den er installeret med en krypteret LVM og krypteret /home-mappe. Det er der ikke noget specielt i. Det er en installationsform, jeg har prøvet mange gange tidligere.

Men denne LVM-installation afviger fra det normale på ét område: Samtidig med den krypterede LVM opretter installeren en krypteret swap-partition.

Som et resultat af den nye installationsmetode skal du, efter genstart af systemet, når installationen er gennemført, starte med at skrive din de-crypt-kode, helt som vanligt. Men efter du har trykket på enter beder systemet om en kode til at de-kryptere den krypterede swap-partition. Her er det så, at det bliver lidt sjovt, eller...

Hvis du skriver din de-krypteringskode, så loader systemet frem til login. Den mere betænkelige del af denne oplåsen af den krypterede swap-partition er, at nøjes du med at taste Enter som kode til at de-kryptere swap så låser systemet swap op og loader til login. Klart en fejl, men vi er méget tidlig i udviklingen.

Den automatisk oprettede kryptering af swap er et godt tiltag at lægge ind i installeren.

Endnu en sjov, halvejs irriterende "feature" er, at du også skal skrive din swap-de-crypt-code når du installerer programmer. Ikke alle, men jeg oplevede det ved installation af software gennem Synaptic.

Vi er meget tidlig i forløbet med wily og du bør IKKE installere den på produktionsmaskiner.

[AJenbo]

Det kan jo være den blot køre uden swap. Egentlig burde det jo være fint hvis den blot selv genere en kryptering af swap så man ikke behøves taste det, ved næste starte kan den blot se swap som tom. Dog ville det ikke kunne virke med dvale da den ikke ville kunne tilgå swap, men det kunne måske løses ved at den oplyser en koden når man vælger at sætte systemet i dvale (ved ikke lige om det ville være sikkert at gøre).

[Jimmyfj]

Fejlen er alvorligere end som så i og med den også eksisterer i Ubuntu 15.04 og findes på alle installationer, som har en krypteret /home. Så det er en bug, som er røget med over i wily også.

Fejlen er systemd-specifik, og er ikke en bug i cryptsetup:

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1449555

Det farlige ved den bug er, at du kan nøjes med at taste Enter (tomt password) for at få systemet til at loade videre.

Man kan argumentere for, at hvis ens adgangskode er svær at cracke så vil der ikke ske noget. Dette er dog en letsindig antagelse, i og med man ikke er klar over hvor omfattende nævnte bug er: Holder den sig til krypteret /home, eller er den en åben dør forbi krypterings-sikkerheden? Kan systemet hackes direkte gennem den bug?

Bug'en har fået høj prioritet på Launchpad, og det er vigtigt at gøre brugere opmærksom på denne bug.

[AJenbo]

Det er ikke et sikkerhedsmæssigt problem, systemet loader blot uden at kunne tilgå /home. Du ville kunne få adgang til det samme med en live-disk. Det er højest et irritations moment at man skal genstarte for at få lov at taste den rigtige adgangkode. Hade det været et sikkehedsproblem ville den have en "Critical" status. Desuden er den rigtige fejlrapport denne:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1453738

[Jimmyfj]

Det er rigtigt. Men bug'en eksisterer både med, og uden fuld-disk-kryptering, altså hvor du ikke opretter en LVM men vælger at kryptere den /home, hvilket så nok er den bug-report, jeg linker til. I begge tilfælde dukker anmodningen om password til swap op, og du kan nøjes med at taste Enter.

Udviklerne har, efter alt at dømme, øje på fejlen, og mon ikke den vil blive rettet.