I'm a user of BOINC under Windows. I'm familiar with the the separate Client and Manager components; the difference between Service mode (runs when no user is logged in) and User mode (required under Windows for GPU computing, because of driver restrictions); how to stop, pause, snooze and restart the client; and much else.

All of these apply to the Linux version of BOINC as well. I think the only significant change to what I've just said is that GPUs can be used in Service mode under Linux.

Because Windows is controlled centrally by Microsoft, there are few active versions in circulation at any one time, and it is relatively easy for the BOINC developers to manage 'one size fits all' in the Windows desktop environment. But Linux is available in multiple different flavours, and with multiple alternative desktop environments (or so I understand - I don't pretend to know the details).

For this reason, BOINC distribution has been largely delegated to the distribution managers who maintain the software installation packages. By default, these distributions of BOINC are installed in Service mode.

There is a move to make the Linux version of BOINC effectively 'Service Mode Only', and to remove certain controls which a Windows would expect to find in their user-mode interface: the ability to snooze the client from the system tray icon, for example, and to 'Shut down the connected client' (local or remote) from the main BOINC Manager menu.

I'm in regular contact with BOINC developers, but I'm not competent to debate the merits or de-merits of this particular proposal. Hence this consultation thread. Please add your comments, and perhaps indicate your particular Linux flavour, and your level of experience with it (advanced, intermediate, beginner, or refugee from Windows...)

Ubuntu 18.10 (soon will change to 19.04) I would class myself as an intermediate user i.e. I can track down the different 32bit libs needed for some BOINC apps and install them without having to look for a post on the subject and copy and paste the commands.

While I could live with losing those commands from the manager I would much prefer to keep them. Under the old system, before the only ways to get an up to date BOINC for Linux were via the package manager and to roll your own (something I have yet to succeed in doing.) I liked being able to download and unpack the files where I chose and run it from there.

Currently I am running the windows version under WINE as no tasks available from CPDN for Linux at the moment.

One other useful information in this context is whether the majority of Linux users are using the packages provided by their distribution or self compiled executables.

This is in essence a discussion about different policies on different platforms and whether BOINC should behave the same on all platforms.

There are two policies or modes that are either or and they can be followed on all platforms. The first is "user mode" and this means that the Client and the Manager run under the context of the currently logged in user. The second is "service mode" and it means that the Client runs under a different context (account) than the Manager. This is not specific to any platform but now it gets tricky on how those modes are implemented in each platform. I'm going to discuss Windows and Linux although Mac behaves roughly the same as Linux.

On Windows there is one Installer file that installs the Client and the Manager. This hides the complexity of the program from the user and is intentional. The user has the choice of installing the Client using his personal account or as a service that runs in the background without the user needing to login and start the manager. We'll just ignore the fact that in both cases the installer creates special accounts that are used to sandbox the scientific application so that they can't access files outside the BOINC data directory since that has nothing to do with the two modes I described.
On Windows the Manager is always started using the currently logged in user and thus is always able to interact with the client because it can start the Client in both modes and the Client will run in the context of the special account that does the sandboxing.

Linux follows a different policy regarding installation packages. They are usually broken into components that can exist individually. In the case of BOINC it means you can install the Client without the Manager and vice versa. Linux also follows a more stricter sandboxing policy which limits privilege escalation. For a normal user it's not possible to run an executable as a different user. That right is limited to the root account. And this is the main difference between Windows and Linux that is relevant for this discussion. Re-read the above paragraph about Windows and now see how this is different on Linux.

On Linux the Client and Manager when installed via the distribution package system are installed using the root account and there usually is a special account for running the Client created (to sandbox the app and also allow it starting as a service). Since this service is not running as the currently logged in user only the root user can control this service. Since the Manager is started as the currently logged in user (which is not the root user!) it can not interact with the service. What it can do is tell a running Client that it should quit using another mechanism that is not relevant here. So in essence: a "service mode" installation on Linux does not behave like one on Windows because the operating system doesn't offer the same possibilities.
A "user mode" installation on Linux is also possible and was done using a downloadable file from the BOINC software project but this file was not updated a long time (6 years) so the only way to have a recent "user mode" installer is by self compiling one. Then the above restrictions don't apply but also the security benefits don't come into play and the Client and the Manager run as the logged in user. This is not advisable.

What I would like to know is how many users are running "user mode" installations on Linux? Why are they doing this? What can we do to reduce this number and switch people over to the "service mode" on Linux?

P.S.: Don't hesitate to ask questions if you don't understand the above and I'll explain better.

I'm going to guess that there is a lot of noise coming from people who want to run 24/7 headless crunch boxes. IIRC that is not the stated application or BOINC. BOINC was intended to be used on computers that did other things but when they weren't busy with other things, do science. Changing that stated purpose shouldn't be done without all the project managers input on what they might expect to happen with their installed user base and what it would mean to them going forward.

Now if the developers want to make a headless version and a GUI version, fine. My thought though is, for a box someone is using to do things other than crunch 24/7 they absolutely need the availability of GUI controls so they can make BOINC get out of the way when they know they are going to do some other processor intensive task.

As to that headless version, perhaps it needs a help function that brings up a window where the common terminal commands can be cut and paste so the users don't have to dig around to find them when they don't use them very often.

An additional thought is that the developer should see his job a bit like the compiler. He makes it easier for the user. He should also be a bit like the optimizer, if it can calculate an expression at compile time, it does, rather than do it millions of times when the program runs.

Perhaps the developers should survey which flavors of Linux are the top 5? 10? environments and concentrate their efforts on those flavors, let others roll their own.

This is not a questions or discussion about splitting the installation on Linux as this has already happened and is a requirement by most Linux distributions. This is also not a problem for normal users and power users. The normal user installs both packages (usually without knowing there are two packages) and the power user that runs 24/7 headless machines only installs the Client package. That is already possible and not a challenge for the developers or the users.

What is the challenge and the reason for Richards question is whether the Manager should behave the same on Windows and Linux. Especially when it comes to starting and stopping the Client (and thus the science applications). AS I described there are some limitations on Linux that hinder the Manager from doing the same things the Manager does on Windows.

Focusing on the top 5 Linux distributions is basically what the BOINC software project already does, since there is no standalone installer anymore.

@ Christian,

I think things have moved on a little since the situation you describe. I used to run BOINC in service mode under Windows XP, but all my recent installations have been in user mode because of the Windows 7 (and later) restrictions on GPU drivers.

So today, as part of this enquiry, I installed BOINC in service mode on a newish, cleanish machine running Windows 10 Pro v1809. I took the plain vanilla installer for v7.14.2 from the download page here. Everything worked as I remembered, and all the stop/start/snooze/suspend/resume controls worked as normal.

Except for one. I could shut down the connected client immediately, but when I tried to restart the Client from the Manager, I had to acknowledge a Windows UAC dialog confirming that I wanted to make changes to the system.

I think that highlights that all communications between the Client and the Manager (information display in one direction, command and control in the other direction) are handled by network RPC protocols: these bypass all the user account and security sandboxes, and explain why you can manage a remote machine in exactly the same way as you manage your local machine (the only possible block is at the firewall level).

Starting the client in service mode, under a different user security regime, is the only time that the Manager has to work with operating system security protocols - and I think that applies equally to Windows and Linux.

Starting the client in service mode, under a different user security regime, is the only time that the Manager has to work with operating system security protocols - and I think that applies equally to Windows and Linux.

Exactly. That is the point I wanted to bring across. On Windows this is solved by asking the user if this action (starting a service) is permitted (you see the UAC screen). On Linux you can also do this of course but there is a different "UAC" system (visual sudo) in every distribution and of course the command to start/restart/stop is different on each distribution depending which init system is used. That makes it harder to achieve the same functionality for a service installation on Linux. The only real problem is really in starting the Client. All other actions like snoozing science apps suspending/resuming or stopping the Client altogether are done using RPC from Manager to Client. But starting the Client as a service when installed via package manager is the hard problem.

But surely that's something the package preparer (repo manager) can configure for the distro they're in charge of? That's where this whole subject originated.

...there is a different "UAC" system (visual sudo) in every distribution...

Users say they only know of gksudo, and it was deprecated in Ubuntu from 18.04

Ubuntu forums suggest sudo -H

Ideas?

Edit - https://bugs.launchpad.net/ubuntu/+source/umit/+bug/1740618

...there is a different "UAC" system (visual sudo) in every distribution...

Users say they only know of gksudo, and it was deprecated in Ubuntu from 18.04

Ubuntu forums suggest sudo -H

Ideas?

Edit - https://bugs.launchpad.net/ubuntu/+source/umit/+bug/1740618

Rephrasing: Every distribution has a different way for a graphical program to gain su permissions. As stated in the bug you quoted the gksu executable was replaced by two different other approaches for a GUI to elevate privileges. It would be a nightmare for a BOINC developer to maintain all those possibilities.

What I can see in the Seti Thread is that the Power Users tend to use self built standalone installations in /home and do not use a service install. For those use cases the Client can be started by the Manager because the Client needs to be started by the user. In the case where the Client was installed by the package manager that is different.

Here is how I understood the initial question about removing the ability from the Manager to stop the Client: When BOINC is installed by a package manager the Manager itself cannot start the Client but it can stop it. So when the user exits the Manager and for whatever reason chooses to shutdown the Client it will stay off until the service or the computer is restarted because no matter how often you start the Manager it can not start the Client. Therefore the ability to stop the Client should be removed. There are clear alternatives to just removing the option and I now wonder why they where never mentioned in the github PR or issue.

Therefore the ability to stop the Client should be removed. There are clear alternatives to just removing the option and I now wonder why they where never mentioned in the github PR or issue.

Here, here. That's why I got involved, and why we're having this discussion.

My feeling is that the advocates of the current issue / PR had a particular (and narrow) view of 'the typical Linux user' - probably guided by the Linux users in their personal workspace - and proposed solutions that seemed natural for that particular stereotypical user.

It would be a nightmare for a BOINC developer to maintain all those possibilities.

Would it be possible for BOINC (centrally) to define a name for a script to be run, and for the package maintainers to define the contents of the named script for their distro?

Therefore the ability to stop the Client should be removed. There are clear alternatives to just removing the option and I now wonder why they where never mentioned in the github PR or issue.

Here, here. That's why I got involved, and why we're having this discussion.

My feeling is that the advocates of the current issue / PR had a particular (and narrow) view of 'the typical Linux user' - probably guided by the Linux users in their personal workspace - and proposed solutions that seemed natural for that particular stereotypical user.

Richard, you and ChristianB seem to continue a discussion that started somewhere else. I and probably most people here don't know its history and therefore I fail to understand your vague references. Not knowing how you see a "typical" Linux system, I guess it's like a "typical" Windows system: A single computer used by a single person who is both the only user and the administrator, with no clear distinction between the roles. I see a tendency to try and turn Linux into something like that and I feel very uneasy about it. Linux is not a free Windows, nor should it be. Windows is a single user system for the Personal Computer. Linux, being inspired by Unix, is by design a multi user system and should be run like that, even if used by a single person. Don't try to make it look, feel and act like Windows, you'll continually fight against its basic design.

For the question of starting the client in a "service" install I second ChristianB, you shouldn't be able to stop what you haven't started. You don't start it in the first place, you can't stop it, you don't need to force a way to re-start it. Simple as that. And remember that BOINC Manager is perfectly capable of managing remote clients just like local clients. How are you going to restart a remote client that was your (the local user's) only connection to the remote system, and you just killed it?

Richard, you and ChristianB seem to continue a discussion that started somewhere else. I and probably most people here don't know its history ...

The discussion seems to be here.

Linux, being inspired by Unix, is by design a multi user system and should be run like that, even if used by a single person. Don't try to make it look, feel and act like Windows, you'll continually fight against its basic design.

Linux has evolved from Unix, so is brilliant as a multi-user system, but it's a bit of hyperbole to suggest that it's fighting against its basic design when used as an extremely capable single user system :-).

For the question of starting the client in a "service" install I second ChristianB, you shouldn't be able to stop what you haven't started.

Except ... you can easily have the best of both worlds by having a simple popup appear that asks for the root password if the user wants to take that action. To my mind this covers both situations - the multi-user environment where only 'responsible' people have that password and the true 'single user is administrator' environment. I would think that most Linux systems that contribute to BOINC projects fall into the latter category so I think single user systems need to be catered for and not overly penalised by complete removal of existing functionality.

How are you going to restart a remote client that was your (the local user's) only connection to the remote system, and you just killed it?

I'm not sure if I properly understand what you mean but if on my machines, I were to shut down a remote client from a local BOINC Manager, I could easily login over ssh and restart that client immediately. For me, I don't particularly care whether or not the functionality is removed from the Manager because I can stop or start clients (I have 100 of them) very simply over ssh. Occasionally, I might use the local manager to view a remote headless client but all my monitoring and control is done by scripts communicating over ssh. The scripts use boinccmd to do all sorts of stuff. I'd be concerned if boinccmd functionality was being removed :-).

---

Cheers,
Gary.

Yes, Gary has identified the correct precursor that led to this discussion (and - when this one got off to a slow start - a parallel discussion at SETI).

It seemed to me that the proposed change - removing, for example, the tools to stop a running client - came from a contributor who was firmly in the 'Linux as multiuser' camp, who had failed to consider the wider environment.

Computer science is evolving all the time. When the Linpack top-500 list was first compiled in June 1993, the top-10 page contained Cray supercomputers with 16 cores, and NEC machines with just four cores. The current (November 2018) top 10 still contains Crays, but the smallest has 387,872 Intel Xeon cores and an unknown number of Tesla P100 GPUs. I think I'd call that a cluster, rather than a computer.

Similarly, operating systems keep evolving. I think that it's wrong to characterise Linux as multiuser and Windows as single user: Gary has made the case for the single-user mode of operation with Linux, but Windows is multi-user, too.

Windows is commonly installed in corporate settings where individual nodes run under group policies centrally set by a Windows server running as a Domain Controller. That even allows features like hot-desking - an individual user with access rights controlled by an administrator can log on to any node on the system, and find that their installed programs, data folders, and even desktop appearance follow them from place to place. But they still wouldn't have the power to install BOINC on any of them. An IT support worker with the (jealously guarded!) master password would have to do that for them. I'm always amused when a public display screen, ticket machine, or bank ATM is stuck on a Windows XP boot error message.

I think that BOINC should be as flexible as possible, and that contributors from one particular historical background shouldn't mould it too rigidly into their particular world-view. But I started this thread to gather alternative opinions, aware that I shouldn't be too rigid about my own world-view, either.

Richard, you and ChristianB seem to continue a discussion that started somewhere else. I and probably most people here don't know its history ...

The discussion seems to be here.

Thank you for the link. So, as I understand it, there's a consensus that user mode boinc on Linux is effectively unsupported. Now there's two opinions. The first is that the ability to start and stop the client in service mode is not needed and should be removed. The other is, while manually starting in service mode is currently not possible, there should be a way to circumvent that restriction. Obviously I'm with the first faction.

Linux has evolved from Unix, so is brilliant as a multi-user system, but it's a bit of hyperbole to suggest that it's fighting against its basic design when used as an extremely capable single user system :-).

That depends on how you define it. To me a Linux system is always a multi user system, even if there's only one person involved. There's always root, and system users like boinc for example, and the next "real" user equal to you is just one useradd away. That "single" user is in no way special just because there is currently no other.

For the question of starting the client in a "service" install I second ChristianB, you shouldn't be able to stop what you haven't started.

Except ... you can easily have the best of both worlds by having a simple popup appear that asks for the root password if the user wants to take that action. To my mind this covers both situations - the multi-user environment where only 'responsible' people have that password and the true 'single user is administrator' environment.

I can't imagine a significant need to take that action from within boincmgr (or boinccmd). Anybody and anything can suspend boinc without any privileges and if it really needs to be stopped or (re-)started, the "responsible" people already have other ways. I would strongly advise against making changes in this sensitive area just to add some rarely used shortcut.

I would think that most Linux systems that contribute to BOINC projects fall into the latter category

No doubt.

so I think single user systems need to be catered for

There's no necessity for a special treatment here, it just makes things more complex without much gain.

not overly penalised by complete removal of existing functionality

Existing non-functionality, partially. As it seems, boinc will already commit suicide on anyone's demand. I never thought this was possible and the feature should really be restricted or better removed. Starting boinc in service mode is not possible as it is and adding the feature IMO is not worth the effort.

How are you going to restart a remote client that was your (the local user's) only connection to the remote system, and you just killed it?

I'm not sure if I properly understand what you mean but if on my machines, I were to shut down a remote client from a local BOINC Manager, I could easily login over ssh and restart that client immediately.

See yourself as multiple personalities and you'll probably understand my thoughts. What does gary@localhost do if he killed the boinc service at remotehost (which IMO he shouldn't have been able to)? As he has no control over remotehost, except for the stupid boinc that is dead now, there's nothing he can do but ask root@remotehost (or equivalent) to take care of the situation. Fortunately that's not too much effort because they happen to be the same person, but that doesn't matter here. What does gary@localhost do if he killed the local boinc service? He'll have to contact root@localhost for the same reasons. Now some people assume they're the same person anyway and want to give gary the opportunity to prove it and have BM take care of the issue instead of root (who is assumed to be gary). My problems with that are

• Is it worth the effort to implement that, with possible security implications, when there already is a working solution?
  
• Can that work remotely? If it can, do we want to give some unknown (there) gary any control over the remote system? If it can't, do we want BM to behave different when controlling remote systems?
  

The scripts use boinccmd to do all sorts of stuff. I'd be concerned if boinccmd functionality was being removed :-).

Do you use boinccmd to stop clients? In that case now you'd need some other way to start them again, and you could also use that way to stop. The question is, should boinccmd (and boincmgr) do both or nothing.

Richard,

sorry just saw your post now. Please see my reply to Gary. I had a look at your SETI thread but haven't found anything to comment on here, other than the people there seem to see the user vs service installation question open. That sounded different from the other thread. As I'm not a SETI user I won't follow the discussion there.

Richard, thanks for the link to the SETI discussion. I've read that now and I think it confirms my opinion that many people who use Linux to crunch BOINC projects, do so in a 'single user' type environment. I was interested to see that many choose to install BOINC under /home with the files owned by themselves for easier editing and the avoidance of permissions issues. I was also interested to see mentioned the lack of the old Berkeley shell archive as a very easy way for an ordinary Linux user to set up their own single user system. It was that lack that forced me to learn how to build BOINC for myself :-). Last time I looked, the packages/generic/sea directory still existed, although I don't bother to build a self-extracting archive. I just take the executables for boinc, boinccmd and boincmgr from their build directories and immediately incoprorate them into a new template tree with the standard set of ancilliary files and the full project tree for my projects of choice, ready to copy into place for a new install.

My personal opinion is that (perhaps at first launch time) a user who has installed the repo package (perhaps in a 'system' area like /var/lib/boinc and owned by a special user 'boinc') should be presented with a series of dialog boxes that get the information needed to properly 'adjust' the install if a single user, self-owned, standalone system (or other particular requirement) is preferred. This would be a script set up by the distro's package maintainer and customised to the particular idiosyncrasies of that distro. It's not really a job for the BOINC developers. Perhaps some sort of 'template' could be provided for the package maintainer or even for the end user if the package maintainer didn't provide a working version. Different packagers (and not just different distros) probably have particular preferences for scripting language and style to be used. On top of that are the different init systems, and different methods for controlling services that exist for different distros.

This approach should benefit any users of a particular Linux distro who are having issues to do with how the package maintainer has set up that particular package and its associated 'adjustment' script. They can immediately give feedback and perhaps resolve the issue locally with the package maintainer without troubling the BOINC developers, or expecting them to be on top of all the idiosyncrasies of hundreds of distros.

One final point to emphasise. There is really no need for the mantra, "If the user didn't start it, the user shouldn't be able to stop it." It should be quite trivial to have a popup window appear and announce something like, "This is a privileged operation. Please confirm by entering the administrator (root) password". Even on my lowly distro of choice, I have a simple icon on the task bar to launch a root shell. If I click it, a simple dialog pops up asking for the root password. If I can get that right, a root terminal session immediately appears. Otherwise access is denied. This happens for lots of point and click stuff where privilege escalation is needed. Utilities like gksu, kdesu, sudo and others are in the repo should I want to build this functionality into any scripts I write. If you want to know why my distros' policy is to frown on the ITMOTB use of sudo, check out this official policy statement If you want to know what ITMOTB stands for, you'll need to read the statement. It's quite entertaining :-).

---

Cheers,
Gary.

That depends on how you define it. To me a Linux system is always a multi user system, even if there's only one person involved. There's always root, and system users like boinc for example, and the next "real" user equal to you is just one useradd away. That "single" user is in no way special just because there is currently no other.

I think you're conflating multi-user with multi-tasking. Linux is a multi-tasking OS that's equally at home with running multiple tasks from whatever number of users the hardware is able to support- from zero to some maximum. My argument is essentially that operations that potentially adversely affect other users of the system (whether they exist or not) should require privilege escalation rather than an outright ban by removing the functionality. The root user should never be permanently logged in - only briefly as required, very much on a temporary basis. I've never said that a single user environment is in any way 'special'. My point is that a multi-tasking system is simply that - able to run multiple concurrent jobs quite independent of how many actual users there are. A BOINC user who chooses to run a Linux system in a "single user" style, and is taking advantage of functionality reserved for a privileged user, has every right to expect that functionality to remain, perhaps under password control to limit potential misuse if the user really didn't have authority to take that action.

I can't imagine a significant need to take that action from within boincmgr (or boinccmd). Anybody and anything can suspend boinc without any privileges and if it really needs to be stopped or (re-)started, the "responsible" people already have other ways. I would strongly advise against making changes in this sensitive area just to add some rarely used shortcut.

I really don't understand your point here. I thought the purpose of this whole thread was to garner user feedback about a proposal to remove some existing functionality from the manager that allowed a user to stop a boinc client under circumstances where they wouldn't be able to restart it without the ability/knowledge to re-launch the service mechanism that started boinc in the first place. Whilst I don't use the functionality personally, I know others do. I'm voting for finding a better way to protect the system than blanket removal of the functionality. Please correct me if I'm not understanding the purpose of this thread.

There's no necessity for a special treatment here, it just makes things more complex without much gain.

I'm not asking for special treatment. I'm asking that a better way than blanket removal of functionality (for everyone and every mode of operation) be found. If an ordinary 'buntu (or derivative) user needed to restart a client killed through the current manager functionality, all they would need to do is run the command

sudo systemctl restart boinc-client

or something like that. I've never used any 'buntu type distro so I'm just guessing. I believe that an ordinary user gets root privileges without a password this way so if the whole idea behind removing functionality from the manager was to improve security, I don't see any improved security where literally anybody with user access could carry out stopping, starting, or restarting the boinc client whenever they liked, irrespective of the capabilities of the manager.

What does gary@localhost do if he killed the boinc service at remotehost (which IMO he shouldn't have been able to)?

localhost and remotehost could be sitting right next to each other or on opposite sides of the planet. With the correct setup (a properly set up secure shell - ssh) it makes no difference. If I want to stop the client on any of 100 different machines that I own, I issue a very simple command as gary@serverhost and it doesn't involve the functionality in the Manager that is currently being discussed. That command is (complete with user prompt)

[gary@serverhost ~]$ ssh $Hnnn "./StopBoinc"

where $Hnnn is a variable defined in gary's .bashrc which contains the hostname of the nnnth host in my farm. The server's /etc/hosts file contains all hostnames and their full IP addresses that the server needs to access. StopBoinc is a bash script that exists on all hosts whose purpose is to run the local boinccmd in the BOINC directory with the --quit option. I have set up full public/private key access between server and client machines so there is no challenge/response or other style of password authentication needed between the machines. The server knows the proper key for each remotehost. Each remotehost knows the proper server key.

For starting the client remotely, there is a similar procedure with a more involved script called StartBoinc for performing basic checks and launching the client. I use the --daemon client option to have the client detach and run in the background when started. Stopping and restarting the client this way while a host is running normally is something that's rarely required but it works perfectly when needed.

As he has no control over remotehost, except for the stupid boinc that is dead now, there's nothing he can do but ask root@remotehost (or equivalent) to take care of the situation. Fortunately that's not too much effort because they happen to be the same person, but that doesn't matter here. What does gary@localhost do if he killed the local boinc service? He'll have to contact root@localhost for the same reasons. Now some people assume they're the same person anyway and want to give gary the opportunity to prove it and have BM take care of the issue instead of root (who is assumed to be gary). My problems with that are

• Is it worth the effort to implement that, with possible security implications, when there already is a working solution?
  
• Can that work remotely? If it can, do we want to give some unknown (there) gary any control over the remote system? If it can't, do we want BM to behave different when controlling remote systems?
  

Even if remotehost wasn't owned by me and if I had no access to root or the root password, I could operate as above as long as I had permission from the owner and as long as the owner was agreeable to the setting up of ssh access as described above. My ssh setup specifically denies root connections over ssh as a security measure. None of the client management scripts I run over ssh require root privileges.

For the way I operate, there is nothing extra to implement so no "effort" at all :-). Yes, it works remotely - I'm doing it. I have no control over other parts (outside of the user's own files) of a remote system if I don't have physical access or the root password. With physical access, I have complete control without any passwords. The proposed changes don't really affect me since I own and have physical access to all machines on which I run BOINC. I figure there'll always be a way to achieve what I want to do.

Do you use boinccmd to stop clients? In that case now you'd need some other way to start them again, and you could also use that way to stop. The question is, should boinccmd (and boincmgr) do both or nothing.

The running client on my machines is not 'owned' by some system process. My interest is purely from the point of view of casual linux users who may have become used to a certain way of running things and may be surprised if that way were to suddenly stop working. I don't think there'll be much of an issue for experienced users but I could easily be wrong.

---

Cheers,
Gary.

Richard, thanks for the link to the SETI discussion.

The discussion has moved on since you read it, and we've had quite a discussion about root and sudo. I'm clearer now, and I've taken the liberty of reposting your ITMOTB link.

I think it's worth reposting part of my latest thoughts here too.

I think the proposal which led to this discussion came from the Debian stable, which I think counts as "real *nix"? The originator's actual words are:

by default on Linux BOINC runs as a service, the GUI must not stop it.

(my emphasis). He seems to be envisaging a situation where an individual using the computer has access to BOINC Manager and can use the tools therein, but doesn't have access to any tool (whether root or sudo) which can restart the service once stopped.

We don't know what any such user might be using the computer for. We do know from discussions here some reasons why a user might wish to stop or snooze BOINC (and I'll come back to the distinction later)

- passive video display (watching a film, without mouse or keyboard activity)
- active video, such as gaming
- thermal control, including reducing noise from the cooling system
- foreground computing tasks requiring fullest resource utilisation

Most of these can be managed automatically by preference settings such as 'suspend while computer is in use' and '[don't] leave tasks in memory while suspended' - which a user with full GUI access can fiddle with. They also have access to daily schedules, so they can set 'BOINC all night, but not when I'm working' or similar.

They can also suspend all projects indefinitely, without limit of time - which might be almost as bad as stopping the service.

The 'snooze' action is distinctively different, because it sets a 60 minute timer: BOINC restarts even if the user has left the building. And it's relevant here, because the same Debian developer has also proposed "Disable BOINC Manager system tray icon on Linux platforms". And 'snooze' can only be invoked from the system tray icon.