:: Re: [DNG] ..maybe webmin?, was: Coc…
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Olaf Meeuwissen
日付:  
To: dng
CC: dng
題目: Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
Hi,

dng@??? writes:

> 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?


When I read[1]

Cockpit itself doesn’t eat resources or even run in the background
when you’re not using it. It runs on demand, thanks to systemd socket
activation.

all I could think of was that inetd and xinetd have been doing that job
for a (couple of) decade(s) already.

The only other mention of systemd on that webpage is one in a longish
"subset of tasks you can perform on each host running Cockpit" that says
you can

Inspect and interact with systemd-based services

That all nice and well if you have any but doesn't seem to interfere
with all the other tasks listed.

[1]: https://cockpit-project.org/

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join