Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
On Mon, Jun 21, 2021 at 06:26:31PM +0900, Olaf Meeuwissen via Dng wrote: > Hi Simon, > > Simon Walter writes: > > > 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. > > I'd cluebat those folks about the CLI first ;-) > > Using adduser/deluser and addgroup/delgroup isn't exactly rocket science > :-P I find myself using these commands so rarely that I have to look up their man pages every time. But every time, they still work perfectly. -- hendrik > > If they don't get that, then they probably shouldn't be adminning users > and permissions to begin with ... > > Just my two yen, > -- > Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 > GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 > Support Free Softwarehttps://my.fsf.org/donate > Join the Free Software Foundation https://my.fsf.org/join > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
Simon Walter writes: > On 6/21/21 6:26 PM, Olaf Meeuwissen wrote: >> Using adduser/deluser and addgroup/delgroup isn't exactly rocket science >> :-P >> >> If they don't get that, then they probably shouldn't be adminning users >> and permissions to begin with ... > > There are managers who have tasted > G-Suite/O365/Some_Cloud_Providers_GUI. If they take full responsibility, > why not empower them? That's why I said >> I'd cluebat those folks about the CLI first ;-) where cluebatting might include a couple of URLs to online versions of the manual pages for these commands. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
On 6/21/21 6:26 PM, Olaf Meeuwissen wrote: Using adduser/deluser and addgroup/delgroup isn't exactly rocket science :-P If they don't get that, then they probably shouldn't be adminning users and permissions to begin with ... There are managers who have tasted G-Suite/O365/Some_Cloud_Providers_GUI. If they take full responsibility, why not empower them? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
Hi Simon, Simon Walter writes: > 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. I'd cluebat those folks about the CLI first ;-) Using adduser/deluser and addgroup/delgroup isn't exactly rocket science :-P If they don't get that, then they probably shouldn't be adminning users and permissions to begin with ... Just my two yen, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
On 6/13/21 7:11 PM, d...@d404.nl 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=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=500=0=default=intitle%3A%22Cockpit%22=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
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
On 15/06/2021 10:42, Olaf Meeuwissen via Dng wrote: > > If projects decide to throw in their lot with systemd > (as in not accepting patches to cater to non-systemd setups), I think > they deserve to be plonked by distributions that don't support systemd. As a matter of interest, can anyone say how often this is happening? -- Mark Rousell ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
tito via Dng writes: > On Sun, 13 Jun 2021 19:41:28 +0900 > Olaf Meeuwissen via Dng wrote: > >> d...@d404.nl writes: >> >> > 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. > > Hi, > would it be possible to start it with a initscript and let it run? > and totally ignore this socket stuff? Probably, but then cockpit would "eat resources". >> all I could think of was that inetd and xinetd have been doing that >> job for a (couple of) decade(s) already. Of course, running (x)inetd also eats resources but the question then becomes whether running systemd consumes more resources then (x)inetd plus your choice of init. # That's assuming you're willing to consider running systemd to begin # with ;-) >> 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 > > Having briefly looked and grepped the source when I removed webmin > from my systems (when it was backdoored) the biggest problem > is that cockpit calls systemctl, hostnamectl and friends directly so > without systemd functionality is crippled as no alternative functions > are provided. It could be an idea and helpful for devuan mastering > the systemd dependency epidemic to create some wrappers for > this systemd binaries as compatibility layer rather than try to modify > every program out there that thinks it needs to depend on systemd, > that way you just modify the dependencies of the cockpit package, > resign it and you are good to go. While I can understand your line of thinking, I think it's a bit of a slippery slope. If projects decide to throw in their lot with systemd (as in not accepting patches to cater to non-systemd setups), I think they deserve to be plonked by distributions that don't support systemd. # FTR, I have no sympathy for cockpit. A (remote) command-line suits me # just fine. Folks not comfortable with that shouldn't be administering # "servers" to begin with, IMNSHO. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
Olaf Meeuwissen via Dng said on Sun, 13 Jun 2021 19:41:28 +0900 >Hi, > >d...@d404.nl writes: > >> 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? In my debates with various systemd fanboiz, I found that the major benefit of systemd socket activation is: "Greybeard, this isn't 1998, today we live in a plug-in world where when you plug in a new device the OS must respond!" OK fine, for sure for sure, now we know the supposed benefit, so we needn't analyze how *systemd* accomplishes the benefit, we need only accomplish the benefit for ourselves. So some time in, as I remember, early 2015, as a proof of concept, I made a shellscript based on inotifywait that would automount on plugin and autodismount on removal. It took me 90 minutes to do it. The design was based on an article that I wrote in The Manjaro Experiments New Years Eve, 2014: http://www.troubleshooters.com/linux/init/manjaro_experiments.htm#inotifywait_m_e_createdelete_devusb There's no reason this functionality should be placed in PID1, and it would be pretty easy to make a standalone daemon to do it. > >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 Poetteristas had a ready made answer for that: "xinetd is so old and [insert insult here]." My view of that is that's just more of their modus operandi: If you can't win the debate on logic, always go for the good old Ad Hominem logical fallacy. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
On Sun, 13 Jun 2021 19:41:28 +0900 Olaf Meeuwissen via Dng wrote: > Hi, > > d...@d404.nl 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=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=500=0=default=intitle%3A%22Cockpit%22=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. Hi, would it be possible to start it with a initscript and let it run? and totally ignore this socket stuff? > all I could think of was that inetd and xinetd have been doing that > job for a (couple of)
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
Hi, d...@d404.nl 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=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=500=0=default=intitle%3A%22Cockpit%22=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
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=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=500=0=default=intitle%3A%22Cockpit%22=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 OpenPGP_signature Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
On 2021-06-10 18:47, Rowland penny via Dng wrote: > On 10/06/2021 10:36, Curtis Maurand via Dng wrote: >> If you’re looking at something like zentyal, you could look at HPE’s >> clearos as well. there is a free version. It does all the things >> that zentyal does. it’s only drawback is that it’s based on centos >> and it’s laced with systemd. >> > > One thing clearos cannot do that zentyal can, it cannot be an AD DC. > That's a pretty big one thing. I would imagine that anyone wanting such an OS would want a fancy GUI for the AD component. Yes, some people still want Windows. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
On 10/06/2021 10:36, Curtis Maurand via Dng wrote: If you’re looking at something like zentyal, you could look at HPE’s clearos as well. there is a free version. It does all the things that zentyal does. it’s only drawback is that it’s based on centos and it’s laced with systemd. One thing clearos cannot do that zentyal can, it cannot be an AD DC. Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
If you’re looking at something like zentyal, you could look at HPE’s clearos as well. there is a free version. It does all the things that zentyal does. it’s only drawback is that it’s based on centos and it’s laced with systemd. —Curtis Sent from my iPhone > On Jun 10, 2021, at 3:31 AM, Simon Walter wrote: > > On 6/8/21 7:05 AM, Arnt Karlsen wrote: >> ..turns out ebox changed its name, and, it does not support Procmail: >> https://zentyal.com/features/ > > It seemed to be going in a good direction, but maybe they didn't have enough > funding. The last version I used was 5. After that, there was no benefit, as > it became too brittle and resource hungry. > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
On 6/8/21 7:05 AM, Arnt Karlsen wrote: ..turns out ebox changed its name, and, it does not support Procmail: https://zentyal.com/features/ It seemed to be going in a good direction, but maybe they didn't have enough funding. The last version I used was 5. After that, there was no benefit, as it became too brittle and resource hungry. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
I’ve been running ispconfig on my beowulf servers for quite some time, now. security model is more like plesk. nobody should be running cpanel. cpanel is dangerous. I had several websites hacked. the attack vector was cpanel. all websites rin under the coanel user. it doesn’t work that way under plesk or ispconfig. ispconfig is free and lacks a native file manager, but who needs them with ftps/sftp options. it will manage ufw as well.if you use it please toss some money their way. Sent from my iPhone > On Jun 7, 2021, at 6:46 PM, 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=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=500=0=default=intitle%3A%22Cockpit%22=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. >> ___ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..maybe webmin?, was: Cockpit removal might make sense
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=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=500=0=default=intitle%3A%22Cockpit%22=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. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
