Gentoo má nové profily 17.0

myslím, že právě naopak, t.j. pokud máte hardened s PIE, pak nejsou potřeba:

If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps...

No, ono je to právě naopak. V newsce píšou doslova toto:

If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps:

Hardened profil používá implicitně GCC se zapnutým PIE, takže ty speciální kroky se mě netýkají, pokud již klasický hardened používám (pro kontrolu viz gcc-config -l, pod profilem hardened). Ve všech ostatních případech to řešit musím, což mě osobně velmi točí, protože už jsem dost strojů přeložil novým GCC a teď to můžu dělat znovu.

Nektere balicky mi to davaji jen s -j1, si to zkuste.

No, sám jsem na to zvědavej u mě. To zase bude knfliktů a keců. Zase budu odebírat balíky a ručně je přidávat zpět, než se systém uspokojí s momentálníma verzema... ALe to není přechodem z 13 na 17, ale mojí neschopností dělat update přiměřeně často... :-)

Na x86 mi to teď visí ve stavu, kdy padá kompilace něčeho kvůli přítomnosti jednoho balíku. Když ho odeberu, zkompiluju to, ale některý balíky ho potřebujou... Ale co, zase je s Gentoo sranda :-D

Nejvíc srandy jsem si užil, když mi to svorně tvrdilo, že perl nový verze nelze nainstalovat kvůli závislostem na sobě samotnym. Unmerge starý verze a při merge nový už přišel ten novej perl a bez keců. Problém? Nikde. Čas strávený všelijakými pokusy a rekompilacemi? Raději neměřit :-D

Jo jo, upgrade PERLu je opich. Iterativně jsem dospěl k následujícímu postupu:
1) upgrade perl-cleaner (emerge -1 perl-cleaner)
2) emerge perlu bez závislostí (emerge -1 --nodeps perl)
3) rebuildnout vše, co na PERLu visí (perl-cleaner --reallyall)

V drtivé většině případů tento postup konverguje k výsledku velice rychle.

Gentoo je distribuce pro lidi, kteří se v Linuxu vyznají. Ti pro linuxovou distribuci nepoužívají označení „tento linux“, a hlavně vědí, že Gentoo je distribuce určená pro průběžnou pravidelnou aktualizaci. Holt vám s Gentoo někdo špatně poradil, pro aktualizaci jednou za čas je potřeba používat distribuce, které jednou za čas vydávají novou verzi (třeba CentOS nebo Ubuntu). Ale pokud ten počítač je připojený do internetu, je potřeba i v takových distribucích instalovat alespoň bezpečnostní aktualizace.

Mám inštaláciu gentoo z roku 2007, ktorú používam na všetkých počítačoch (upravené march podľa potreby). Aktualizácie robím prevažne skriptami. portage a distfiles mám spoločné na serveri, slabšie stroje využívajú výkon servera cez distcc. Kompilácia nie je problém, kľudne pri nej dokážem pracovať. Na strojoch mám väčšinou 16GB RAM, takže aj kompilácia je celá v RAM a nemám žiaden problém.
Keď vieš ako narábať s Gentoo, tak to ide takmer samo a bez problémov.

Porusili jste pravidlo #1 administratora: "Jestli to jede, tak na to nesahej" :)

Ja tvoji poznamku chapu, pokud by sis prostudoval zaklady systemu, tak bys pochopil, cim je tato situace zpusobena a take zjistil, jakym zpusobem aktualizovat stare instalace.

https://wiki.gentoo.org/wiki/Upgrading_Gentoo:

Plus mas k dispozici i navod na to, jak aktualizovat hodne stare instalace :-)
https://wiki.gentoo.org/wiki/Upgrading_Gentoo#Updating_old_systems

Já jedu Gentoo řadu let, ale do updatu po dvou letech bych se ani já nechtěl pouštět. Ne, že bych to nezvládl... :-P

Jel jsem na gentoo celých 15(??+-) let. Na desktopu, a několik let na serveru. Zlatej systém. Zejména ze v začátcích kde byl každej kompilací získanej tik procesoru znát a jiné distribuce nenabízely některé softvéry a tak je bylo nutno tak jako tak kompilovat...

Ale doba pokročila, já jsem zase o něco zestárnul, a nejak mě začalo štvát právě to spravování po každým updatu. Ano, updatoval jsem kolikrát klidně i po půl roce, ale doteď to tak nějak šlo. Jenže ona se nabalovala celková složitost, počet use flagů (kolik jich má teď vlc?), zastaralé balíky a, ano, chyby. Takže naposled když jsem naposledy zase upgradoval. Dopadlo to přesně jak popsal autor.

Přesedlal jsem na desktopu na arch a jsem více-více-méně spokojen.

Na serveru bych zůstal u gentoo.

Uz jsem nekolikrat zatim neuspesne :-) (skoncili jsme pouze na urovni debat na foru nebo irc), a nejenom ja, rozjizdel iniciativu, jak udelat z Gentoo binarni distribuci pri zachovani vsech vyhod, ktere gentoo dava.

Slo by to to navrhnout a provozovat nejakou globalni infrastrukturu, ktera by uzivatelum poskytovala predkompilovane binarni balicky dle jejich konfigurace (config fingerprint).

V zasade jsem se dostali vzdy pri debatach na takovyto postup

1. Anonymne zacit sbirat konfiguraci systemu (installed packages a cely obsah /etc/portage)
2. Nasledne rozparsovani techto dat a vyhodnoceni, ktere sestavy jsou nejvice pouzivane. Aby se proste nekompilovaly jen dummy vsechny mozne kombinace.
3. Zacit provozovat online distcc clustery, ktere by kompilovaly package podle skoringu do queue podle sebranych konfiguraci z bodu 1, vysledky by se ukladaly na binarni host.
4. Pokud jdu nasledne kompilovat, tak muj lokalni system online zjisti jestli je balicek pro moje sestaveni (CFLAGS, USE flags, etc.) k dispozici v binarni forme, pokud ne, tak ho budu kompilovat zaroven lokalne i za pomoci volnych zdroju distcc klusteru. Samozrejme nektere package toto neumoznujou, takze by dochazelo k automatickemu failover kompilovat jenom lokal, nebo jenom remote. V druhem pripade by uzivatel cekal, az bude balicek k dispozici pres globalni binhost. Samozrejme pouziti PKI a symetrickych sifer pro komunikaci a sifrovani dat apod.
5. Binhost by mel funkci offline replikace. Aby si lide mohli provozovat na svych sites svoji instanci, ktera by pouze synchronizovala balicky z globalniho hostu a poskytovala je lokalne serverum bez moznosti internetoveho pripojeni, neco jako Nexus pro java nebo docker images, etc.

Dost jsme resili bezpecnost a asi jednim takovym predikatem, ze je nemozne aby, lokalni uzivatel neco kompiloval a pak to sdilel do binarniho hostu. Vsech nabizeno na binarnim hostu by musela byt pouze produkce zabezpeceneho distcc clusteru pod kontrolou Gentoo komunity.

Jelikoz vidim, ze je tu spousta Gentoo uzivatelu, tak se ptam, jestli by nekdo nemel zajem na tomto experimentovat. Ja mam v soucasne chvili asi 248 jader pro distcc v privatnim DC.

Ted jsem se dostal k instalaci na Dell XPS 13 a opet jsem plakal. Ale i na serverech by to instalaci urychlylo.

Pokud by mel nekdo zajem, tak se mi ozvete: archenroot {at} gmail {dot} com

*oprava: instalaci urychlilo - pardon za hrubku

Diky za feedback. Ohledne kombinaci. Proto je tam prvni krok sber lokalnich konfiguraci

1. budou se pouze kompilovat kombinace, ktere uzivatele chteji
2. dale by se u nektery packages, nebo use flags dala tato remote funkce uplne vypnout

Chapu, ze se bavime v nekterych pripadech o astronomickych cislech.

Ja zas pouzivam Gentoo i na serverech, desktopech a laptopech. Gentoo komunita investuje hodne casu do dekstopu nejruznejsich typu a prave tychlost nahozeni si myslim, by mohla pomoci alespon trochu adopci novych uzivatelu.

Distcc asi v server prostredi ano, v desktopu, laptop hure. Jde take o to, ze by si system dokazal zjistit, jake package se musi buildovat lokalne, jake napr. jen s MAKEOPTS=-j1, apod. a vlastne by dochazelo i k ladeni packages na pozadi.

Ten sber konfiguracnich dat by mohl byt vyuzit nejenom pro tento napad, ale dal by zpetnou vazbu Gentoo councilu o pouziti systemu, architektur, konfiguraci (chapu, ze ne vsichni by to tam posilali, protoze proste systemy nemaji zadnou internetovou konektivitu napr. v produkci, nebo to lide nechteji). Minimalne ten sber dat mam uz kompletne navrzeny s REST API backendem.

Dalsi pozitivni vliv vidim automaticke generovani bugu na nejakem centralnim build clusteru.

Diky za pripominky.

Dalsi vec je, ze by se nesestavovaly baliky po vsech use flags, ale po groups of flags.

Firefox-bin a firefox (source) nemaji stejne use flags, tj. ani dnes Gentoo nenabizi binarni balicek presne pro konkretni sestaveni, ale spise ve smyslu, dostanes skoro vsechno. To same se da udelat pro apache, ffmpeg. Cimz opet cela komplexita klesa.

Pozn: Ale stale plati, ze tu nejde o naplneni vsech kombinaci, ale pouze o ty, ktere uzivatele opravdu pouzivaji.

Jeste doplnim, situace, jdu kompilovat napr. Apache s nejakym setem use flags. portage posle dotaz, zda sestaveni existuje jako binary, pokud ne, necha ho na remote clusteru sestavit a je mi dodany jenom binarni balicek. V nekterych pripadech se ten binarni balicek nemusi na centralnim binhostu ani ukladat, protoze prave vystupem muze byt velky pocet kombinaci. takze se to jenom bude kompilovat on-demand.

Ten prinos je v tom, ze globalni distcc infrastruktura by byla uz odladena. Kdokoli delal na ruznych architekturach distcc (powerpc, arm, x86), tak snad uzna, ze kazda unikatni konfigurace prinasi sve vlastni problemy, ty jsou vyreseny, ale znalosti jsou ztraceny, resp. nedostupne pro ostatni po svete. To je dalsi prinost. Tech prinosu je tam skryto opravdu vice, nez to na prvni pohled vypada.

Dale treba ikdyz nechces nebo nemas ze serveru pristup na internet. Mohl bys si komplet konfiguraci vykopirovat z globalni pro svou lokalni instanci. Nebo naopak rucne nakopirovat svoji lokalni zpet, pokud jeste neexistovala.

Jeste doplnim, situace, jdu kompilovat napr. Apache s nejakym setem use flags.
To ale přece nestačí. Závisí to ještě na kompilačních závislostech, jejich verzích a na tom, jaké mají nastavené use flagy, a stejným způsobem to mohou ovlivnit i tranzitivní závislosti.

Jak nestaci? psal jsem, ze portage sebere a provede tzv configuration fingerprint, tj. cluster vi, jake se maji buildit verze. Opravdu by slo vlastne o nejakou sluzbu distcc, samozrejme by tam byl nejaky wrapper pres http, ktery by fungoval asi takto:

RX(input) - lokalni konfigurace bud kompletni /etc/portage obsah, nebo jen vystup z konkretniho volani emerge na specifickou package
TX(output) - jeden,nebo vice balicku v binary

Ale in general souhlasim, server musi mit samozrejme vsechny informace, aby vedel co jde delat...

Ja jsem si zrovna ted o vikendu postavil mobilni server (chci to narvat do dr zaber sentry case) zalozeny na 18 jadernem (36threads) E5-2697 v4 (sehnal jsem ho za 13 tisic korun LOL, ES verzi teda ). Kompiloval jsem si tam plasma-desktop. Ani ne plnej plasma-meta balik, a i tak to trva proste dlouho. Ja uz dnes instaluju gentoo pres jeden pulstrankovej slozenej prikaz :-), abych u toho nemusel sedet, ale z meho pohledu je stale 10 minut na package hodne...

Samozrejme si tady identifikoval krasnej priklad na package qtwebengine, qtwebkit, ktera by byla dobra v binarnim formatu. Jde o to, ze soucasne binarni balicky nepodporuji stejny use flag selection. ma taky malo use flags napriklad oproti ffmpeg.

Cela tahle moje iniciativa je zalozena na predstave dostat full desktop install ready do jedny hodiny max. A slo by o kombinaci dostupnych balicku binary s vykonnym compilacnim clusterem. Ja sam jsem treba ochotnej na to dat nejakou infrastrukturu do zacatku a sponzorovat to i par tisicema mesicne. Ale chtelo by to vic lidi, ktery by projevili zajem na tom hlavne pracovat. Nemam na to casove abych z toho udelal one man show i z duvodu rychlosti dokonceni.

Trupiku, jeste to sem postnu nejak trochu jednoduseji, ackoli jsem to psal nize.

Ta tvoje uvaha je matematicky spatne, resp. sedi jenom jako cista kombinatorika, ale zde musis vysledek namapovat na dostupne instance. Instance je jeden Gentoo system running na planete zemi.

A s otisky se to ma takhle
Otisk configurace v case = jedna gentoo instance
Otisk configurace se muze menit

Otisk configurace ma zavyslost 1:N k otiskum produkovanych binarek.

Realny pocet otisku, o kterem se bavime, je z meho pohledu radove mensi a nema co delat s kombinacemi, ktere uvadis. To realne cislo bude daleko mensi, rekl bych ze smesne :-) co rikas?

Ale diky za feedback, pokud se ve sve uvaze pletu nejak, dej mi prosim vedet.

Diky za konfirmaci, protoze uz jsem z toho taky nekdy zblblej a nevim, ktera bije :-)

No uz jsem v kontaktu s Gentoo devs, ze bych se stal taky Gentoo dev, protoze bych rad dostal AI frameworky do hlavni vetve.

Prvni krok bude naimplementovat odesilani anonymnich konfiguraci na nejaky centralni server pres REST API, oni se budou sbirat 3 otisky ke 3 kontentum:
- emerge --info | sha512sum
- find /etc/portage -type f -exec sha512sum {} \; | sort -k 2 | sha512sum
- eix-installed -a |sha512sum

POZN: Kazdy request bude mit unikatni fingerprint systemu:
dmidecode -t 4 | grep ID | sed 's/.*ID://;s/ //g' |sha512sum

Nejdrive se odeslou na server jenom tyto fingerprinty, server odpovi, ze je budto zna (a incrementuje pouziti, pouzije fingerprint systemu, aby to byli jen unikatni requesty), pak se nic nedeje, nebo odpovi, ze je nezna, na to portage reaguje tim, ze dodatecne odesle cely kontent ale pouze k neznamemu fingerprintu. Tim se zefektivni a zrychly cely proces eliminaci posilani dat, ikdyz nejsou potreba.

Cele se to bude ridit promennou v /etc/portage/ma­ke.conf:
SHARE_ANONYMO­US_USAGE_STATIS­TICS="yes"

Mam hotovy prototyp ciste v pythonu (klient), backend REST API jsem vyvinul v Jave (SpringBoot, Spring Data Rest a JPA), backend je MongoDB (nosql document databaze).

Takze doufam, ze do tohoto programu se take zapojis. Tyhle informace se budou dat vyuzit na kouncilu ohledne preferenci napr. nebo priorit ve strome balicku.

Ted budu muset vyjednat integraci do portage a zjistit, kam vydeployjovat ten backend, kdo tobude managovat, apod.

No a az toto pobezi treba pul roku a nasbira "dost dat" (co to vlastne je dost dat???) :-), tak se bud ano, nebo nepustim do toho open clusteru.

Ten system bude operovat na otisky konfiguraci, on se nesnazi komputovat vsechny moznosti, jak napr. nekdo uvadel viz vyse ze mame 2*80 kombinaci pro apache. Ale to neni pravda! Takova uvaha je spatna, protoze pocita, ze mame k dispozici 2^80 pocitacu, kde je nainstalovat, ale my je nemame, to same plati pro kompilaci jakychkoli balicku. My jsme limitovani realitou, coz je v tomto pripade dobre. Takze veskere uvahy co do poctu instanci moznosti jsou omezene poctem instalaci Gentoo :-)))

Ad bezpecnost i toolchain libs uz diskutujeme viz vyse....ale kratce

Kombinace use flags (genericky na urovni jakekoli package, nezajima me toolchain, apod. to je vsechno jen package).
Ty vidis nutnost pokryti vsech kombinaci, ale to neni realita. Ty mas pouze jednu kombinaci v case a zadas system aby pro tebe udelal nejake operace:
1- dej mi binarku jestli ji mas pro moji kombinaci
2- zkompiluj ji pro me nezabezpecene,tzn. nekdo uz prede mnou kompiloval stejnou kombinaci, ale server neukladal binarku (na zaklade konfigurace), ale ma ulozeny otisk binarky. Takze open cluster zkompiluje v jedne instanci a server overi vysledek otiskem.
3- zkompiluj ji pro me zabezpecene,to znamena, ze pro server je tato kombinace uplne nova

Ad 3 - to je varianta ohledne zabezpeceneho procesu.

Jeden z konceptu je, ze poprve se neznama konfigurace zkompiluje paralelne, vzdy na jinych, nebo jine kombinaci nodu (2, nebo 3? independent kompile procesy minimalne). Vysledky (binarka a logy) jdou na nejaky gentoo server, a pokud jsou stejne, vytvori se otisk a binarka se preda klientovi. Backend dodatecne rozhodne, zda ulozi jen otisk binarky, nebo binarku celou (podle skoringu). Pokud nejsou otisky stejne, klient failoveruje do lokalniho kompile modu automaticky, nahlasi se problem a jeho detaily. Timto zpusobem nebude potreba mit velke naklady na gentoo infrastrukturu.

Dalsi koncept je, ze Gentoo bude compile cluster bude vzdy ten, ktery kompiluje balicky a generuje k nim otisky. Pokud je rozhodnuto, ze po kompilaci se binarka neuklada a nekdo v budoucnu chce stejnou configuraci, lze ji jiz spustit na uzivatelskem clusteru jelikoz vysledek se jen porovna s otiskem. Tim ale davame na gentoo infrastrukturu burden v podobe nejeno backend dataze a analytiky, ale take je potreba platit vypocetni cluster.

Tento druhy koncept muze fungovat, protoze cluster bude stale buildid na zaklade aplikace fronty, tj. bude prednostnekom­pilovat kombinace s vice uzivateli. Uvedomme si take, ze bych planoval stahovani data behem pul roku-1 roku, kdy uz paralelne muze bezet vytvareni balicku na backendu. Takze jakmile se vyda portage upravena o cele reseni, spousta realnych kombinaci uz bude k dispozici at uz v binarni podob

Poznamka nakonec: Opravdu prosim neuvazujte ze je nekde velke mnozstvi kombinaci. Proto uvazuju ten system jako event driven, tj. Hypoteticky je rozsahly co do poctu moznych sestaveni, ale pokud se neprovede prvni krok ve forme sberu dat a neudela se nad nimi analyza, tak je to pouze slepa spekulace. tzn. kdyz ja reknu, ze pocet kombinaci je maly a vy budete rikat, ze je urcite vetsi nez muj, tak mame oba pravdu :-))).

V zasade backend udrzuje tyto entity pro predstavu nejakeho modelu:
1. otisk konfigurace systemu
Tato informace se generuje na zaklade obsahu /etc/portage, pripadne plus emerge --info.
Backend nezna neco jako system (podle IP apod), Takze pokud neco upravim a posilam pozadavek vytvori se novy otisk
V teto entite jsou rozparsovane vsechny global, local use flags per package + make.conf, apod, ale ulozi se to jako nejaky document v jednom lobu (forma JSON napriklad)
2. otisk konfigurace package
Po pozadavku na urcitou package se vytvori otisk package, ale zaroven jejich dendency tree.
Opet se ulozi k otisku i dokument obsahujici celou konfiguraci (verze a flags) + cela konfigurace dependency tree

Otisk konfigurace systemu a package muze byt M;N, tj. ruzne systemy mohou mit stejne otisky package

3. Posledni je otisk binary vysledku doplneny pripadne o link ulozene binarky (pokud se bude ukladat)
otisk binarky je 1:1 k otisku konfigurace