De release van het systeem voor zelfvoorzienende pakketten Flatpak 1.4.0.

Geplaatst een nieuwe stabiele tak van de toolkit Flatpak 1.4, die een systeem biedt voor het bouwen van zelfstandige pakketten die niet aan specifieke Linux-distributies zijn gebonden en uitgevoerd worden in een speciale container, die de applicatie van de rest van het systeem isoleert. Ondersteuning voor het uitvoeren van Flatpak-pakketten is beschikbaar voor Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint en Ubuntu. Flatpak-pakketten zijn opgenomen in het Fedora-repository en worden ondersteund in de standaardapplicatiebeheerder van GNOME.

Belangrijkste vernieuwingen In de Flatpak-tak 1.4:

  • De organisatie van de instellingen voor externe repositories is gewijzigd. In de map /etc/flatpak/remotes.d worden in plaats van *.conf-bestanden met instellingen nu gewone «.flatpakrepo»-bestanden gebruikt, die automatisch worden geïmporteerd bij het eerste gebruik van flatpak. Deze bestanden kunnen vrij worden bewerkt en verwijderd, net als handmatig toegevoegde repositories;
  • De organisatie van de installaties van beschikbaar systeem brede pakketten is aanzienlijk gewijzigd. In eerdere versies werd het pakket eerst geïnstalleerd in een tijdelijke map die aan de gebruiker toebehoorde, waarna een system-helper-proces werd aangeroepen om het vanuit deze map in het systeem te importeren. Deze aanpak leidde tot een groot verbruik van schijfruimte, overbodige invoer/uitvoer en potentiële beveiligingsproblemen. In de nieuwe versie wordt voor de installatie van systeempakketten een speciale nieuwe FUSE-bestandssysteem gebruikt, waarin de gebruiker gegevens kan schrijven, maar na het schrijven wordt de toegang tot deze bestanden voor de gebruiker geblokkeerd. Deze nieuwe aanpak houdt in dat voor flatpak een aparte gebruiker moet worden aangemaakt (standaard «flatpak») en dat de SELinux-regels moeten worden gewijzigd;
  • De mogelijkheid is toegevoegd om aan de cliëntzijde filters voor externe repositories te definiëren. Met behulp van filters kan het zichtbare aanbod van applicaties in de repository worden beperkt met een wit- en zwartlijstmodel;
  • Een bibliotheek-API is toegevoegd voor het toevoegen van externe repositories vanuit flatpakref-bestanden;
  • Een seccomp-profiel is toegevoegd voor Docker, waardoor flatpak binnen containers kan worden uitgevoerd;
  • De mogelijkheid om van meerdere P2P-bronnen (via USB-opslagapparaten of via een lokaal netwerk) te installeren is verbeterd;
  • In het commando «flatpak remote-ls» is automatische filtering van applicaties die niet meer worden ondersteund geïmplementeerd;
  • In «flatpak remote-ls» en «flatpak remote-info» is de optie «—cached» geïmplementeerd om informatie te geven op basis van lokaal gecachete gegevens;
  • De mogelijkheid is toegevoegd om de versie van de vervaldatum van het pakket op te geven, waarna er een voorstel zal verschijnen om over te stappen naar een nieuwe tak;
  • De optie «—socket=pcsc» is toegevoegd om toegang te krijgen tot smartcards;
  • Ondersteuning is toegevoegd voor systemen met meerdere NVIDIA-videokaarten;
  • Ondersteuning is geïmplementeerd voor dconf in een sandbox-omgeving;
  • In het build-update-repo team zijn opties toegevoegd zoals «—no-update-[summary,appstream]» en «—static-delta-ignore-ref=PATTERN»;
  • De snelheid van het regenereren van appstream-takken is aanzienlijk verhoogd voor grote repositories.

Laten we niet vergeten dat Flatpak ontwikkelaars in staat stelt de distributie van hun programma's te vereenvoudigen, die niet in de standaard distributierepositories zijn opgenomen, door het voorbereiden één universele container zonder aparte builds voor elke distributie. Voor gebruikers die om veiligheid geven, stelt Flatpak in staat om twijfelachtige applicaties in een container uit te voeren, waardoor alleen toegang wordt verleend tot netwerkfuncties en bestanden van de gebruiker die met de applicatie verband houden. Voor gebruikers die geïnteresseerd zijn in de nieuwste ontwikkelingen, maakt Flatpak het mogelijk om de nieuwste test- en stabiele versies van applicaties te installeren zonder wijzigingen in het systeem aan te brengen. Bijvoorbeeld, momenteel zijn Flatpak-pakketten al gebouwd voor LibreOffice, Firefox, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, enz.

Om de bestandsgrootte van het pakket te verkleinen, bevat het alleen afhankelijkheden die specifiek zijn voor de applicatie, terwijl de basis systeem- en grafische bibliotheken (Gtk+, Qt, GNOME en KDE bibliotheken, enz.) worden gepresenteerd als aan te sluiten typische runtime-omgevingen. Het belangrijkste verschil tussen Flatpak en Snap is dat Snap gebruikmaakt van componenten van de basissysteemomgeving en isolatie op basis van filtering van systeemaanroepen, terwijl Flatpak een aparte container van het systeem creëert en werkt met grote runtime-sets, waarbij als afhankelijkheden niet pakketten, maar typische systeemomgevingen worden verstrekt (bijvoorbeeld alle bibliotheken die nodig zijn voor het draaien van GNOME- of KDE-programma's).

Naast de typische systeemomgeving (runtime), die via een speciale repository, worden aanvullende afhankelijkheden (bundle) geleverd die nodig zijn voor de werking van de applicatie. Samen vormen runtime en bundle de inhoud van de container, waarbij runtime apart wordt geïnstalleerd en aan meerdere containers kan worden gekoppeld, zodat duplicatie van gemeenschappelijke systeembestanden voor de containers wordt vermeden. Binnen één systeem kunnen verschillende runtime-versies (GNOME, KDE) of meerdere versies van één runtime (GNOME 3.26, GNOME 3.28) geïnstalleerd zijn. De container met de applicatie als afhankelijkheid gebruikt alleen de koppeling naar een specifieke runtime, zonder rekening te houden met de afzonderlijke pakketten waaruit runtime bestaat. Alle ontbrekende elementen worden direct samen met de applicatie verpakt. Bij de vorming van de container wordt de inhoud van runtime gemonteerd als onderdeel van /usr, terwijl de bundle in de map /app wordt gemonteerd.

De inhoud van runtime en applicatiecontainers wordt gevormd met behulp van technologie OSTree, waarbij het beeld atomisch wordt bijgewerkt vanuit een Git-achtig opslagplaats, wat het mogelijk maakt om versiebeheer methoden op de componenten van de distributie toe te passen (bijvoorbeeld, het is mogelijk om het systeem snel terug te zetten naar een vorige staat). RPM-pakketten worden via een speciale laag naar de OSTree-repository vertaald. rpm-ostree. Het apart installeren en bijwerken van pakketten binnen de werkomgeving wordt niet ondersteund; het systeem wordt niet op componentniveau bijgewerkt, maar geheel, atomair zijn status verandert. Er zijn middelen beschikbaar voor incrementele toepassing van updates, waardoor een volledige vervanging van het image bij elke update niet nodig is.

De gecreëerde geïsoleerde omgeving is volledig onafhankelijk van de gebruikte distributie, en met de juiste pakketconfiguraties heeft het geen toegang tot de bestanden en processen van de gebruiker of het hoofd systeem, kan het niet direct communiceren met hardware, behalve via DRI voor uitvoer, en met het netwerk subsystem. Grafische uitvoer en invoerorganisatie geïmplementeerd met behulp van het Wayland-protocol of via doorsturen van de X11-socket. Interactie met de externe omgeving is gebaseerd op een DBus-berichtenuitwisselingssysteem en een speciale API Portals. Voor isolatie de DNS-server van CloudFlare wordt gebruikt, zal in Chrome slechts de methode van de DNS-verwerking worden bijgewerkt naar een equivalente service, zonder wisseling van de DNS-provider. Bijvoorbeeld, als een gebruiker in de systeeminstellingen de DNS 8.8.8.8 heeft opgegeven, zal in Chrome laag Bubblewrap en traditionele Linux-technologieën voor containervirtualisatie, gebaseerd op het gebruik van cgroups, namespaces, Seccomp en SELinux. Voor geluidsuitvoer wordt PulseAudio gebruikt.

Bron: opennet.ru

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers 🔥 Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster