Development for LHC@home

This new version makes use of systemd-run. In order to use it correctly sudo will need to be configured for the boinc user. This can be done with the prepare_theory_native_environment script.

A special thanks goes to computezrmle for this contribution.

Reply to post https://lhcathomedev.cern.ch/lhcathome-dev/forum_thread.php?id=630&postid=8165 from the meanwhile outdated thread.
Jerome_C2005 wrote:

I'm sorry I have no idea how to get that script (and then run it) in command line from the no-GUI debian VM I'm using for LHCdev :/


edit : I actually have another debian on a VM on my iMac that I have never used for LHC, there (I think) that I could run that script now, and attached it to LHCdev and I got native tasks (for both theory and atlas) but (obviously) all is failing because I never ran all the stuff that needs (install applications, setup... ) to be done to run the native applications... (I never intended to do it on that machine)

If you explain me how to run the script on my no-GUI VM (that one is not a VM in my mac, it is a small hosted machine on a cloud provider) I'll give it a try

To be honest, I don't know what you expect.

You got a link to download a script and have been asked to run that script.
Use wget or curl to download it, then run it.
This is basic knowledge and not related to BOINC or LHC.
Well, here is a oneliner doing it for you:

sudo /bin/bash -c "export script=\"prepare_theory_native_environment\" && wget https://lhcathomedev.cern.ch/lhcathome-dev/download/$script -O /tmp/$script && chmod u+x /tmp/$script && /tmp/$script && rm /tmp/$script"

Beside that it is a must for years to have a local CVMFS client installed and correctly configured before you can run native tasks.
I wonder why you ignore that and instead post complaints about failing tasks.


What you may have missed:
ATLAS tasks on this server are currently generated by an automatic loop with a minimum of events.
Since the ATLAS responsible has left CERN months ago there's currently nobody at CERN who takes care of the results.

Hence, it makes no sense to run any ATLAS tasks.

This new version makes use of systemd-run. In order to use it correctly sudo will need to be configured for the boinc user. This can be done with the prepare_theory_native_environment script.

A special thanks goes to computezrmle for this contribution.

This is the success to do NOTHING from my side to let -native running.
21:24:15 CEST +02:00 2023-09-05: cranky-0.1.0: [INFO] Checking local requirements.
21:24:15 CEST +02:00 2023-09-05: cranky-0.1.0: [INFO] Found Sudo-Version 1.9.5p2.
sudo: Ein Passwort ist notwendig
21:24:15 CEST +02:00 2023-09-05: cranky-0.1.0: [INFO] Can't find or read '/etc/sudoers.d/50-lhcathome_boinc'.
21:24:15 CEST +02:00 2023-09-05: cranky-0.1.0: [INFO] Missing 'CVMFS_HTTP_PROXY="auto;DIRECT"' in '/etc/cvmfs/default.local'.
21:24:15 CEST +02:00 2023-09-05: cranky-0.1.0: [INFO] Can't find '/etc/cvmfs/domain.d/cern.ch.local'.
21:24:15 CEST +02:00 2023-09-05: cranky-0.1.0: [INFO] Can't find '/etc/cvmfs/config.d/cvmfs-config.cern.ch.local'.

Sorry Stefan, we are people to help Cern_IT:
Thank you Laurence to integrate some new feature.
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=3238432

Just to mention it:
For years all apps from LHC@home -dev and -prod (except SixTrack) include code that I suggested and Laurence or other responsibles accepted.

The error messages that you post are caused by missing requirements your system simply does not fulfil.
Either because it is outdated or you just did not run the script Laurence mentioned.
In addition the -dev project is the right place to identify exactly those issues.

no comment.

Beside that it is a must for years to have a local CVMFS client installed and correctly configured before you can run native tasks.
I wonder why you ignore that and instead post complaints about failing tasks.

This kind of comment is not necessary and is a proof you have not understood my context, the machine I run native has been successfully running native theory and atlas *for years*, the 2nd VM was just a test to see how to run the script itself.

I ran your command

jerome@xxxx:~$ sudo /bin/bash -c "export script=\"prepare_theory_native_environment\" && wget https://lhcathomedev.cern.ch/lhcathome-dev/download/$script -O /tmp/$script && chmod u+x /tmp/$script && /tmp/$script && rm /tmp/$script"
[sudo] password for jerome: 
/tmp/: Is a directory
jerome@xxxx:~$ 

I'm not sure if "/tmp/: Is a directory" is any sort of confirmation of success, or error.

So on that machine I was then able to create the script from Laurence using nano + copy/paste from the page where the script is visible + make script executable + run it with sudo, I had no output and no error, I assume "it must have ran successfully".

We'll see once it gets more tasks.

no comment.

On est bien d'accord, l'excès de melon nuit au cerveau.

I think your script broke something on my debian :

jerome@xxxx:~$ sudo apt update
>>> /etc/sudoers.d/50-lhcathome_boinc_theory_native: syntax error near line 17 <<<
>>> /etc/sudoers.d/50-lhcathome_boinc_theory_native: syntax error near line 18 <<<
sudo: parse error in /etc/sudoers.d/50-lhcathome_boinc_theory_native near line 17
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
jerome@xxxx:~$ 

It did not even ask my password and there are clear reference to lhc native app instead, like "sudo was corrupted" or something : what the heck ?

What can I do now ?

So on that machine I was then able to create the script from Laurence using nano + copy/paste from the page where the script is visible + make script executable + run it with sudo, I had no output and no error, ...

... I assume it must have ran successfully".

Probably NOT.

Login as root and run:
ls -hal /etc/sudoers.d
cat /etc/sudoers.d/50-lhcathome_boinc_theory_native

Post the output of both commands.


If you run an sudo version below 1.9.10 it will not understand regular expressons.
Hence you also don't need the sudoers file.
In this case remove it (as root):
rm /etc/sudoers.d/50-lhcathome_boinc_theory_native*

debian@xxxx:~$ ls -hal /etc/sudoers.d
ls: cannot open directory '/etc/sudoers.d': Permission denied
debian@xxxx:~$ 

debian is supposed to be the admin user of that VM, I found back the automated mail the provider sent me when it was created and it says "administrative account", appart from mine ("jerome") that I added long ago do sudoers, I have no other account to my knowledge.

Obviously now I can't do anymore "sudo xxx" anywhere, I showed the errors I get above.

I have been always done "apt update" and "apt upgrade" on that VM so I don't see why sudo wouldn't be up to date, but yes the version is 1.8 and I have no idea how to force the install of 1.9

Package: sudo
Version: 1.8.27-1+deb10u5
Priority: optional
Section: admin
Maintainer: Bdale Garbee <bdale@gag.com>

Besides now it can't use apt anymore at all

debian@xxxx:~$ apt update
Reading package lists... Done
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied)
W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied)
debian@xxxx:~$ 

So what I can do now ?

Sudo is a central feature in Linux, for me CentOS.
We need for this password problem help from Cern-IT.

On the remote computer login as normal user, then run the following commands (without leading line numbers):

1. grep -E '(root|debian)' /etc/passwd
2. su - root
# enter real root's password when asked
# ensure you are real root (not 'debian')
3. whoami
4. id -u $(whoami)
5. ls -hal /etc/sudo*
6. cat /etc/sudoers.d/50-lhcathome*

Post the output from commands (1.)-(6.)

I got fed up and I killed the VM, I reinstalled a (more recent) debian 12 from scratch (using the "reinstall" of the provider, it's pretty quick = I assume their robot just copies a ready-to-go debian image), they sent me an automated email with login information with an admin user to start with (only one), and guess what : it is not admin, not root, I can't do anything, all is refused... they don't provide the password for root itself, they deliver tons of documentation maybe it is explained but I have no will or time to try to figure out right now.

I opened a ticket to the provider, we'll see.

Then I'll see if I have the courage to reinstall all the stuff for native theory and native atlas... or if I just use it with some other project.

Thanks for your help anyway.