On 6/13/21 7:11 PM, dng@??? wrote:
> 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?
>

That part is trivial, as others have said, inetd and similar will
suffice. The part that needs to be written is cockpit-bridge - FWICT.
That seems a bit pointless unless there is an extremely clean separation
between cockpit-ws and cockpit-bridge. What you'd be doing is using the
cockpit framework to create your own bridge to a non-systemd OS. If
there is any kind of codependency and the two are intertwined, then
you'd be better off writing a browser GUI from scratch. Lots of the
design goals of cockpit are admirable and make it stand out compared to
webmin, plesk, and cpanel. My favorite one is "Cockpit uses APIs that
already exist on the system. It doesn’t reinvent subsystems or add a
layer of its own tooling." We know that is not the case with others. I
remember trying to customize Zentyal was difficult because of their
state layer.

Anyway, I tend to be sympathetic to people like Olaf "A (remote)
command-line suits just fine." It's when you need to delegate
administration of users and permissions to someone who does not know the
CLI. Then you wish for a decent GUI.

Best regards,

Simon