I'm going to implement it into the configuration, which will assure that is it going to be the last step executed after a reboot.

@hagbard Note that a reboot does fix the ability to edit configuration again until the next time the cron script runs.

In T1178#30992, @kroy wrote:

@hagbard Note that a reboot does fix the ability to edit configuration again until the next time the cron script runs.

Where do you have the script content set up? In /config/scripts/vyos-postconfig-bootup.script?

The latest rolling did seem to correct the base problem. That being cron scripts running breaking the ability to edit config afterwards.

But, that rolling was terribly broken in some other ways, and I'm not sure if it was related. Basically, most routing seemed to break.

I had the content in my script commented out, which means the task scheduler was essentially running nothing. But as soon as the task scheduler would run, I would lose all connectivity to the VM over L2TP/IPsec. I was able to quickly access via OOB, and reboot into EPA3.

When I'm not remote, I can take a closer look to see if I can figure out what was breaking.

The 'commit' causes the issue, but right now I'm not sure why.

OK, I think I found it, however so far I can only give you a quick workaround rather than solving it.
Short explanation, if you setup cron, your script is executed as root which changes the permissions for the configs on union-fs and the directories, that's why already a set fails, it can't simply write as user vyos to the directory.
To get your stuff working, try the following (preferably on a test box, I used the rolling from tonight but any 1.2 image should work if it's not older than 3 months or so)

1. sudo vi /etc/cron.d/vyos-crontab (use nano if you prefer nano)
2. in there you see line like:

*/3 * * * * root /home/vyos/Test.script
change it to:
*/3 * * * * vyos /home/vyos/Test.script

Then wait the 3 minutes and check the result, it should now work and you should the still be able to use the conf mode in the cli with no issue.

What I have to find out it is it should be the vyos user for any cronjob. If that's the case it's an easy fix, otherwise, well I have to think about that one.

Let me know how it goes.

@kroy install http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-10_all.deb and try again, I have the changes in that package and tonights rolling will have it too. I couldn't find anywhere a requirement that the cronjobs need root, so I switched it to always run as vyos which keeps the file system permissions intact. Test it on a test machine first, but it should now do what you want, I used your script code from above, but didn't have any real ospf adjacency with any other route, but that shouldn't matter at all. Let me know the results please.

Depending on the task which needs to be executed a script might need to be run as root.

Running as user vyosis incorrect as this is only the default user and that user might be deleted (as I do on all my nodes)

cpo@LR1:~$ cat /etc/passwd | grep vyos
cpo@LR1:~$

I'm not aware of the possible sideeffects when running a cronjob as a user which is non existing.

@cpo it would just exit 1. I gotta look into the possibility to see the commit user, I was under the assumption that the vyos user always exists. If there are multiple (at least 2 different) and the cron runs a root or the user (the one which did not setup the job), it will disable any config for all other users, since the filesystem permissions change. ACL's would be something which can solve it, but I have to verify it. I'll keep this task open to track it. Do you just replace the vyos user, or are you using root only in your config?

@hagbard I remove/change the vyos user too. So it's definitely a breaking change.

I wouldn't execute a scheduled script. Thats all. Do you recreate then a different user? Since all users have admin privs, the probem with the change permissions will persist. Actually makes it works, one user can block the other. So, I have to find something else out.

Yeah. I remove the initial vyos user and add an admin and an ansible user. The admin is just for consistency across different devices.

Thanks for confirming. With 2 users, you may encounter always the issue that a cronjob locks up your ability to change the config afterwards. For now the manual workaround should help you, I'm going to revert my changes from yesterday and return to the drawing board.

OK, so the issue happens only if a) the cronjobs was executed by root and b) it modifies the config (which gets then rewritten via union-fs). I created another user called test01, the user vyos has a cron job in his name, regardless what user (test01 or vyos) the script runs, all stays healthy. As soon as the script is triggered via root, you can't set anything in your running config due to the permission changes I wrote yesterday.

If you change a user or create a user (there is no operator level account anymore by the way, that option can be removed), they are assigned all to the required groups, root however is not, it stays root:root.
(https://blog.vyos.io/the-operator-level-is-proved-insecure-and-will-be-removed-in-the-next-releases) - but I don't see the changes in the rolling release by the way.

So I think If I can find a why for the scheduler to find out what user triggered the commit, that would be the ideal solution for that problem.

Until then @kroy, please use the manual workaround posted above for now.

All right, can you please test: https://github.com/hagbard-01/vyos-1x/releases/download/1.2.0-10/vyos-1x_1.2.0-10_all.deb

I modified the task scheduler script to use the id of the user who calls commit, that user will be the user who executes the job. That way the filesystem permissions will stay intact. However there is a flip side of the coin, which would require to rewrite the task scheduler script.

If you have 2 users, lets say vyos01 and vyos02 and the user vyos01 creates the task for cron, the vyos-crontab will have vyos01 as the user who executes the script. Now when vyos02 changes let's say the time interval for the job, the script will after the commit run as user vyos02. But ir will run and won't break your config anymore.

@kroy , @c-po can you please provide feedback when testing the package above? If it works well, I make the necessary changes upstream, currently you won't see the changes in any release, which also gives you currently the option to downgrade to the original vyos package if mine causes issues.

@hagbard I replaced vyos user with another one. Also image corporate setups where RADIUS is used for authing and there are no local users.

Using you packages creates:

cpo@LR1# cat /etc/cron.d/vyos-crontab
### Generated by vyos-update-crontab.py ###
*/5 * * * * cpo sg vyattacfg "/usr/bin/logger foo"
[edit]

after a reboot the node is gone

cpo@LR1# show system task-scheduler
Configuration under specified path is empty

@c-po
*/5 * * * * cpo sg vyattacfg "/usr/bin/logger foo"

That is unexpected, I just do a call for the user via os.getlogin() and put that user in there.
sg vyattacfg is something you put in as command? That avoids the issue kroy has, since it is correctly setting the group permissions.

The second issue is expected, I discovered it today as well, the task-scheduler script needs some TLC, it just drops the file and that's it. If you only call commit and not save, the file stays in place but is gone from the config. That is currently an issues in all releases.

Nope, I used:

cpo@LR1# show system task-scheduler
 task foo {
     executable {
         arguments bar
         path /usr/bin/logger
     }
     interval 5m
 }

My system login id says:

cpo@LR1:~$ id cpo
uid=1003(cpo) gid=100(users) groups=100(users),4(adm),6(disk),27(sudo),30(dip),107(frrvty),109(vyattacfg)

This procides an entry in the system log every 5 minutes: Jan 23 09:05:01 LR1 cpo: foo

Thanks that helps, I gotta review. Remote authenticated users would act like local ones by the way, pam would resolve it or if it can't be resolved, con exits with 1.

@c-po All right, found it. Try it without arguments, then it ends up just as */5 * * * * root /usr/bin/logger which causes the issue. That shouldn't be too hard to fix, the existence of the cronjobfile after a reboot without the save command however is a longer journey.

Found the bug, https://github.com/hagbard-01/vyos-1x/releases/download/1.2.0-10/vyos-1x_1.2.0-10_all.deb should fix it. As soon as You guys can confirm, I push it upstream.

@c-po @kroy can you test it please if you have time?

Anyone?

Sorry. Spent the week restoring almost half a petabyte of data from backups due to a ZFS crash.

Tested it out and it it seems to work fine. Thanks!