:: Re: [DNG] ..maybe webmin?, was: Coc…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: dng@d404.nl
Fecha:  
A: dng
Asunto: Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
On 08-06-2021 00:46, Hendrik Boom wrote:
> On Tue, Jun 08, 2021 at 12:05:39AM +0200, Arnt Karlsen wrote:
>> ..snip "tech" justification of subversive systemd politics.
>>
>>> So in summary, there is no way of running cockpit in a
>>> non-systemd/Linux environment that I'd be willing to support.
> Most of the worries mentioed here seem a bit overblown, but still
> need to be considered.
>> ..found just 3 mentions of "systemd", and this gem in:
>> https://metadata.ftp-master.debian.org/changelogs//main/c/cockpit/cockpit_243-1_changelog
>> "- Detect unregistered RHEL systems on Software Updates page"
> But I did look at those mentions of systemd. The one I found
> worrisome was the first:
>
>    * Add smoke autopkgtest that can run in containers.
>      Add a simple test of cockpit-bridge and the login page to ensure that
>      packages have the right dependencies and contents, and that the systemd
>      units are set up correctly to get a login page on
>      https://localhost:9090.
>      This can also run in a container and thus in Debian's CI and on all

>
> If systemd becomes an integral par of Debian's packaging system,
> it may cause us difficulties.
>
> -- hendrik
>> ..now, Martin Pitt does offer a good recommendation:
>>> For these I'd rather recommend looking at webmin, ebox, or similar
>>> project."
>> ..https://alternativeto.net/software/cockpit-linux/
>>
>> ..to maintain e.g. webmin (https://www.webmin.com/ )
>> support for cockpit, you may wanna look at these 2: ...
>> "https://packages.debian.org/sid/cockpit-bridge
>> Cockpit bridge server-side component
>> The Cockpit bridge component installed server side and runs commands
>> on the system on behalf of the web based user interface."
>> ...and "https://packages.debian.org/sid/cockpit-tests
>> Tests for Cockpit
>> This package contains tests and files used while testing Cockpit.
>> These files are not required for running Cockpit." ...
>>
>> ...and check systemd and cockpit brass thinking: ...
>> https://packages.debian.org/sid/cockpit-doc
>> "Cockpit deployment and developer guide
>> The Cockpit Deployment and Developer Guide shows sysadmins how to
>> deploy Cockpit on their machines as well as helps developers who
>> want to embed or extend Cockpit."
>>
>> ...against: https://packages.debian.org/source/sid/cockpit
>> and the possible potential Ken Thompson style hacks:
>> https://duckduckgo.com/?q=Ken+Thompson+style+hacks&ia=web
>>
>> ..and, who needs a compiler with systemd onboard? My guess is systemd
>> running as PID1, can be set up to launch such possible "Ken Thompson
>> style hack" attacks, all you need to do is hide them away in binaries
>> somewhere "neccessary" online, so these new Cockpit web admin user
>> systemd victims never understand them, even if they ever find out how
>> to read such C etc code...
>>
>> ..on cockpit and alternatives:
>> https://www.unixmen.com/cockpit-a-beginner-friendly-server-administration-tool/
>> https://www.linux-magazine.com/Issues/2020/241/Cockpit
>> https://www.hostingadvice.com/how-to/cpanel-vs-plesk-vs-webpanel/
>> https://alternativeto.net/software/webmin/
>> https://en.wikipedia.org/wiki/Comparison_of_web_hosting_control_panels
>>
>> ..cockpit is not known by Wikipedia:
>> https://en.wikipedia.org/wiki/Cockpit_(disambiguation)
>> https://en.wikipedia.org/w/index.php?title=Special:Search&limit=500&offset=0&profile=default&search=intitle%3A%22Cockpit%22&ns0=1
>>
>>
>> ..turns out ebox changed its name, and, it does not support Procmail:
>> https://zentyal.com/features/
>>
>> ..webmin supports procmail.
>>
>> -- 
>> ..med vennlig hilsen = with Kind Regards from Arnt Karlsen
>> ...with a number of polar bear hunters in his ancestry...
>>    Scenarios always come in sets of three:
>>    best case, worst case, and just in case.


Not hindered by any knowledge about system programming I am wondering
how much work it would be to implement a socket activation interface
without systemd. Although what I read about its design it is unnecessary
complicated. Using a tinylog component in systemd until syslogd is
loaded is one example of such complicating solution.

Has anyone invested some time in analyzing systemd's  socket activation
and mind to share it on this list or in email?

Grtz

Nick