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] USB mount problem
Le 23/06/2021 à 14:38, Dr. Nikolaus Klepp a écrit : > Anno domini 2021 Wed, 23 Jun 13:34:39 +0200 > Didier Kryn scripsit: >> Le 23/06/2021 à 12:49, Dr. Nikolaus Klepp a écrit : >>> Anno domini 2021 Wed, 23 Jun 12:16:50 +0200 >>> Didier Kryn scripsit: [...] There is no other way to know which partitions are mounted or not than read /proc/self/mounts. inotify does not work on pseudo-filesystems like /sys or /proc. Therefore, either this is done by the front-end or by the back-end. >>> Oh, inotifywatch perfectly works on /sys and /dev when you are root, in >>> fact that's what I use as part of my automounter when I run fvwm: >> Of course it works on /dev; tmpfs and devtmpfs behave like real >> filesystems. This is what Hopman is based on (~: >> >> Hopman isn't root, doesn't need to be, and shouldn't be. And inotify >> doesn't work on /proc (at least for non-root). > Well, inotifywait does work on /dev /sys and /proc for non-root, too. At > least it does here on chimaera. Just try these: > > $ inotifywait -rm /proc/ > $ inotifywait -rm /sys/devices/pci* > > What does not work is /sys/block, but that's a cosmetic problem, as you alway > can watch for /sys and fiilter the output. I don't need to poll or watch /sys. I browse it when inotify tells me something about /dev, to see if it is a partition and if it is removable. > > How does hopman differ from e.g. "inotifywait -rm /dev/disk" or "inotifywait > -rm /dev/block" + some lines of shell magic to get a nice output? Because It does it all in just one single process and also browses /sys to filter events as explained above and all the rest of the work: display the status, collect mouse-clicks, launch helpers, wait() them, display their error messages, all asynchrohously. It is easy to make a toy script to play with it but really unpractical to do a complete job. > If polling /proc/self/mounts is required, where is the point in not polling > /sys/block/sd*/removable, too? 1st because polling one file only is less load for the system; 2nd because when there are no removable device in the system, then there is no need to poll it, and this is most of the time. As long as there is no removable device, Hopman is sleeping 100% the time, except briefly when a file is created/deleted in /dev. Reading /proc/self/mounts is triggered by an alarm which is enabled only when there is a removable device in the system. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] USB mount problem
Anno domini 2021 Wed, 23 Jun 13:34:39 +0200 Didier Kryn scripsit: > Le 23/06/2021 à 12:49, Dr. Nikolaus Klepp a écrit : > > Anno domini 2021 Wed, 23 Jun 12:16:50 +0200 > > Didier Kryn scripsit: > >> [...] > >> There is no other way to know which partitions are mounted or not > >> than read /proc/self/mounts. inotify does not work on pseudo-filesystems > >> like /sys or /proc. Therefore, either this is done by the front-end or > >> by the back-end. > > Oh, inotifywatch perfectly works on /sys and /dev when you are root, in > > fact that's what I use as part of my automounter when I run fvwm: > > Of course it works on /dev; tmpfs and devtmpfs behave like real > filesystems. This is what Hopman is based on (~: > > Hopman isn't root, doesn't need to be, and shouldn't be. And inotify > doesn't work on /proc (at least for non-root). Well, inotifywait does work on /dev /sys and /proc for non-root, too. At least it does here on chimaera. Just try these: $ inotifywait -rm /proc/ $ inotifywait -rm /sys/devices/pci* What does not work is /sys/block, but that's a cosmetic problem, as you alway can watch for /sys and fiilter the output. How does hopman differ from e.g. "inotifywait -rm /dev/disk" or "inotifywait -rm /dev/block" + some lines of shell magic to get a nice output? If polling /proc/self/mounts is required, where is the point in not polling /sys/block/sd*/removable, too? Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] USB mount problem
Le 23/06/2021 à 12:49, Dr. Nikolaus Klepp a écrit : > Anno domini 2021 Wed, 23 Jun 12:16:50 +0200 > Didier Kryn scripsit: >> [...] >> There is no other way to know which partitions are mounted or not >> than read /proc/self/mounts. inotify does not work on pseudo-filesystems >> like /sys or /proc. Therefore, either this is done by the front-end or >> by the back-end. > Oh, inotifywatch perfectly works on /sys and /dev when you are root, in fact > that's what I use as part of my automounter when I run fvwm: Of course it works on /dev; tmpfs and devtmpfs behave like real filesystems. This is what Hopman is based on (~: Hopman isn't root, doesn't need to be, and shouldn't be. And inotify doesn't work on /proc (at least for non-root). -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] USB mount problem
Anno domini 2021 Wed, 23 Jun 12:16:50 +0200 Didier Kryn scripsit: > [...] > There is no other way to know which partitions are mounted or not > than read /proc/self/mounts. inotify does not work on pseudo-filesystems > like /sys or /proc. Therefore, either this is done by the front-end or > by the back-end. Oh, inotifywatch perfectly works on /sys and /dev when you are root, in fact that's what I use as part of my automounter when I run fvwm: # # inotifywait -rm /sys/ Setting up watches. Beware: since -r was given, this may take a while! Watches established. /sys/class/ OPEN,ISDIR power_supply /sys/class/power_supply/ OPEN,ISDIR /sys/class/ ACCESS,ISDIR power_supply /sys/class/power_supply/ ACCESS,ISDIR /sys/class/ ACCESS,ISDIR power_supply /sys/class/power_supply/ ACCESS,ISDIR /sys/class/ CLOSE_NOWRITE,CLOSE,ISDIR power_supply /sys/class/power_supply/ CLOSE_NOWRITE,CLOSE,ISDIR /sys/devices/system/cpu/cpufreq/policy0/ OPEN scaling_cur_freq /sys/devices/system/cpu/cpufreq/policy0/ ACCESS scaling_cur_freq /sys/devices/system/cpu/cpufreq/policy0/ CLOSE_NOWRITE,CLOSE scaling_cur_freq /sys/class/ OPEN,ISDIR power_supply /sys/class/power_supply/ OPEN,ISDIR ... # inotifywait -rm /dev/char/ Setting up watches. Beware: since -r was given, this may take a while! Watches established. /dev/char/ CREATE 189:135 /dev/char/ CREATE 188:0 /dev/char/ ATTRIB 189:135 ... # inotifywait -rm /dev/block Setting up watches. Beware: since -r was given, this may take a while! Watches established. /dev/block/ CREATE 8:16 /dev/block/ CREATE 8:18 /dev/block/ CREATE 8:17 /dev/block/ ATTRIB 8:17 ... Nik > > > > > >> Both Hopman-cli and the GUI must read hopmanrc at startup (it seems > >> simpler to have a single file to configure both). Possibly the name of > >> the GUI application might be specified in hopmanrc and Hopman-cli would > >> launch it. > > What's configurable in hopmanrc? Shouldn't it "just work" for all > > partitions/devices? The GUI part most likely will need some config, e.g > > automounting certain devices/partitions etc. > > hopmanrc provides a lot of possiblities to parameterise the > application, such as window appearance, behaviour and position, location > of pid-file and helper applications to mount/umount/open/eject > partitions/devices. > > -- Didier > > > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ 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] USB mount problem
Le 23/06/2021 à 11:50, Dr. Nikolaus Klepp a écrit : > Hi! > > Anno domini 2021 Wed, 23 Jun 00:00:11 +0200 > Didier Kryn scripsit: >> Le 22/06/2021 à 19:10, Steve Litt a écrit : >> [...] >> Hopman-cli would write to the pipe 3 sorts of messages, with all the >> necessary details: >> >> - a device special file associated to a removable partition has been >> detected in /dev >> - a symlink has been detected in /dev/disk/by-label, pointing to a >> removable partition >> - a device special file associated to a removable partition has been >> removed > IMO this sounds good. I would just make it react on all partitions, not only > the removable: there are broken devices out in the wild that lie about their > removability. And there are devices that have wrong entries in the hw > database (e.g. old Casio cameras). No, Hopman should not show /home, /var, etc... Currently it relies on /sys to tell which device is removable. Removable partitions might also be declared in the config file as regular expressions. > > Oh, hopman would only send data, not receive from the client side, would it? > >> [...] >> Then it's up to the GUI application to >> >> - parse these messages, maintain and display a list of removable >> partitions and their labels, >> - on click, spawn helpers to mount/umount/open partitions and >> potentially eject disks, check completion and report errors, >> - periodically read /proc/self/mounts and report mountpoints of >> removable partitions on the display. > Why parse /proc/self/mounts? IMO it would make more sense if hopman-cli sends > " mounted on yyy" or "xxx unlounted" over the pipe, as it is already > monitoring stuff. There is no other way to know which partitions are mounted or not than read /proc/self/mounts. inotify does not work on pseudo-filesystems like /sys or /proc. Therefore, either this is done by the front-end or by the back-end. > >> Both Hopman-cli and the GUI must read hopmanrc at startup (it seems >> simpler to have a single file to configure both). Possibly the name of >> the GUI application might be specified in hopmanrc and Hopman-cli would >> launch it. > What's configurable in hopmanrc? Shouldn't it "just work" for all > partitions/devices? The GUI part most likely will need some config, e.g > automounting certain devices/partitions etc. hopmanrc provides a lot of possiblities to parameterise the application, such as window appearance, behaviour and position, location of pid-file and helper applications to mount/umount/open/eject partitions/devices. -- Didier ___ 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] USB mount problem
Hi! Anno domini 2021 Wed, 23 Jun 00:00:11 +0200 Didier Kryn scripsit: > Le 22/06/2021 à 19:10, Steve Litt a écrit : > [...] > Hopman-cli would write to the pipe 3 sorts of messages, with all the > necessary details: > > - a device special file associated to a removable partition has been > detected in /dev > - a symlink has been detected in /dev/disk/by-label, pointing to a > removable partition > - a device special file associated to a removable partition has been > removed IMO this sounds good. I would just make it react on all partitions, not only the removable: there are broken devices out in the wild that lie about their removability. And there are devices that have wrong entries in the hw database (e.g. old Casio cameras). Oh, hopman would only send data, not receive from the client side, would it? > [...] > Then it's up to the GUI application to > > - parse these messages, maintain and display a list of removable > partitions and their labels, > - on click, spawn helpers to mount/umount/open partitions and > potentially eject disks, check completion and report errors, > - periodically read /proc/self/mounts and report mountpoints of > removable partitions on the display. Why parse /proc/self/mounts? IMO it would make more sense if hopman-cli sends " mounted on yyy" or "xxx unlounted" over the pipe, as it is already monitoring stuff. > Both Hopman-cli and the GUI must read hopmanrc at startup (it seems > simpler to have a single file to configure both). Possibly the name of > the GUI application might be specified in hopmanrc and Hopman-cli would > launch it. What's configurable in hopmanrc? Shouldn't it "just work" for all partitions/devices? The GUI part most likely will need some config, e.g automounting certain devices/partitions etc. Oh, udisksctl as mount-helper will make the job easy :) Nik > [...] -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] USB mount problem
Didier Kryn said on Wed, 23 Jun 2021 00:00:11 +0200 >Le 22/06/2021 à 19:10, Steve Litt a écrit : >> Didier Kryn said on Tue, 22 Jun 2021 18:00:17 +0200 >> >>> Le 22/06/2021 à 14:20, Steve Litt a écrit : > Both Hopman-cli Let's call it Hopman-Backend. It shouldn't have to do any user interface work of any kind: Just implement an API or Domain Specific Language (DSL). If somebody wants a CLI (Command Line Interface) front end to it, that could be developed using ncurses, dmenu etc. > and the GUI must read hopmanrc at startup (it seems >simpler to have a single file to configure both). I disagree with the single file. Tom wants to use a Python/Tk front end. Dick wants to use a GTk front end. Harry wants to use a CLI front end. Each of those front-ends should have its own config. If this is structured right, the only thing the front end should need to know about the back end is the filenames of any fifos, pipe files, etc. Naturally, the API or DSL should be in a file available to the back end and any front end. > Possibly the name of >the GUI application might be specified in hopmanrc and Hopman-cli would >launch it. That works for me. Or just put the front end as a command line arg to the back end. One of them has to launch the other, unless we want a process manager/supervisor to run the back end at boot. > > Both applications must die immediately when the pipe is broken. That sounds doable. > > I don't think the GUI is a piece of cake, but you seem to have some >experience (~: Not really. The only thing is, the front end is just a front end that interoperates with the API or DSL. My program would do nothing complicated. I actually wrote something similar in 1986, command line interface, on DOS, in order to interact with a VAX miles away. Worked just fine. The VAX guys gave me the commands the VAX expected and the responses it put out, and I just made the front end. > Note that this a reactive program: it must react on >input data available, I assume you mean input data *from the backend* *to the front end* is available. I can handle that with polling or by having the back end throw a signal at the front end. If the back end forked the front end, then the front end knows the PID to signal. > mouse-click, If I'm understanding correctly, reacting on mouse-click is what GUI front ends do. > and child-termination, Which child? > while >periodically reading /proc/self/mounts. Periodically reading /proc/self/mounts is something the back end would do. > I think the most difficult is >to check the result of helpers and forward their messages to the user. I'm not familiar with helpers. The way I visualize it, when the back end has new data for the front end, it writes that data to a pipe or file or whatever, and then signals the front end (perhaps SIGUSR1). Once the front end has the data, it's the front end's job to translate the raw data to something easy to digest for the user. > > If this seems too difficult, Hopman-cli could take care of mount >helpers, but this would require a bidirectional communication, making >it impossible to launch both applications from the command-line >(Hopman-cli should be in charge of launching the GUI). hopman-init hopman-backend my_hopman_frontend hopman-init's whole purpose is to receive the PID of hopman-backend and inform hopman-backend of its own PID. Hopman-backend then forks my_hopman_frontend, so hopman-backend gets the PID of my_hopman_frontend during the fork. Hopman-backend later informs my_hopman_frontend of hopman-backend's PID as data. So each can signal the other when there's data ready. By the way, when I did something similar to the preceding paragraph, some of my friends told me there's a better way than signalling data ready with a signal. I forgot what they told me though. 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
