| View previous topic :: View next topic |
| Author |
Message |
LabBrat
n00b
Joined: 21 Mar 2023
Posts: 4
|
 Posted: Sun Jun 25, 2023 8:28 pm Post subject: A tool that automatically updates Gentoo Linux |
 |
|
Hello everyone, I hope you are having a great time of day 
I am coding a program to automate and simplify Gentoo Linux updates.
Wrote about it in detail in the blog: https://blogs.gentoo.org/gsoc/2023/06/25/gentoo_update-introduction/
It will be awesome to get some feedback on the idea 
What features should it have?
What are some common problems that you are facing during upgrades that would be nice to address?
Any feedback/suggestion/contribution is welcome  |
|
| Back to top |
|
 |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3477
|
| Posted: Sun Jun 25, 2023 11:03 pm Post subject: |
|
|
Sorry to burst your bubble, I see 3 problems here:
1) we already have a tool for easy updates, it's called "portage" and we invoke it with command "emerge"
2) you have your priorities backwards: you're looking for a problem that can be solved with coding instead of looking for ways to code towards your objective
3) please tick the checkbox below:
[ ] I'm not a robot |
|
| Back to top |
|
|
fpemud
Guru
Joined: 15 Feb 2012
Posts: 350
|
| Posted: Mon Jun 26, 2023 3:06 am Post subject: |
|
|
I raise my hand to support this project.
sys-apps/portage lacks some features, such as:
1. auto resolve circular dependencies
2. auto fallback to an (stable) old version if the newest version (~*) fails when installing a new package
These features are not only difficult to implement, but also require some custom policies as prerequisites.
So I think it would be a good thing if there were some small projects or scripts, that wrap sys-apps/portage (preferably a library separated from it, maybe sys-apps/pkgcraft?), provide "one click" experience for various scenarios. |
|
| Back to top |
|
|
carcajou
Apprentice
Joined: 10 Jun 2008
Posts: 248
|
| Posted: Mon Jun 26, 2023 6:52 am Post subject: Re: A tool that automatically updates Gentoo Linux |
|
|
| LabBrat wrote: |
What features should it have?
What are some common problems that you are facing during upgrades that would be nice to address?
|
It's funny because last weekend I mocked up a simple bash script to automate my personal update process.
Except the very rare blockers, I do not have particular issues with Portage. Considering new Gentoo users are your main target, some of the ideas off the top of my head:
[*] the tool should have a direct way (a simple flag) to deal with Portage niceness (depending when you update the system)
[*] merge time estimation (I use "genlop -p" for this)
[*] "health" report - to check the sanity of set compile flags, number of jobs (set/recommended), non-merged config files etc. |
|
| Back to top |
|
|
LabBrat
n00b
Joined: 21 Mar 2023
Posts: 4
|
| Posted: Mon Jun 26, 2023 7:44 pm Post subject: |
|
|
| szatox wrote: |
1) we already have a tool for easy updates, it's called "portage" and we invoke it with command "emerge"
|
Yeah "Portage" and "emerge" are awesome, but for me personally it takes quite a bit of time in a week (2-2.5 hours) to handle updates.
And it would be nice to just automate it
| fpemud wrote: |
I raise my hand to support this project.
|
Thank you 
| fpemud wrote: |
2. auto fallback to an (stable) old version if the newest version (~*) fails when installing a new package
|
This is pretty cool, and I think it's doable in the scope of this project.
I guess there could be a choice, either the program can try to fix the issue or fallback to the last stable version, and the user will decided on this.
| kukibl wrote: |
[*] the tool should have a direct way (a simple flag) to deal with Portage niceness (depending when you update the system)
[*] merge time estimation (I use "genlop -p" for this)
[*] "health" report - to check the sanity of set compile flags, number of jobs (set/recommended), non-merged config files etc.
|
It's a good point about Portage niceness, I am using an old crappy Acer laptop and often run into Portage consuming all my resources 
Would you say "genlop" is accurate in the estimation? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54736
Location: 56N 3W
|
| Posted: Mon Jun 26, 2023 8:31 pm Post subject: |
|
|
LabBrat,
genlop works with elapsed time, no CPU time.
If you | Code: | | emerge firefox thunderbird libreoffice --jobs=3 |
Then run any of them alone, the lone one will faster (elapsed time) but will require the same amount of CPU time.
Both answers are equally accurate.
szatox,
Do not stand in the way of someone attempting the impossible.
Remember the Wright brothers.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3477
|
| Posted: Mon Jun 26, 2023 10:15 pm Post subject: |
|
|
Neddy, no worries. TBH I did not really expect him to return after linking not only 1 but 2 websites in his first message ever, yet here we are. Oh well, perhaps he's not a robot after all.
| Quote: | | Yeah "Portage" and "emerge" are awesome, but for me personally it takes quite a bit of time in a week (2-2.5 hours) to handle updates. |
2 hours is a very long time, I only spend a few minutes on trivial maintenance and don't really see how adding another tool would make it faster. A small change to config-protect-if-modified could make it better though.
So, why won't you use your current experience with portage to sort out the priorities for this project?
What do you do during those 2 hours? Is it 2 hours per machine, or do you have a full DC worth of servers you handle during that time?
Also, do you want to actually make something usable, or is it mostly a coding exercise? Nothing wrong with doing code exercises, but those 2 things will probably benefit from different approaches. |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3007
Location: Edge of marsh USA
|
| Posted: Tue Jun 27, 2023 3:16 am Post subject: |
|
|
| LabBrat wrote: | Yeah "Portage" and "emerge" are awesome, but for me personally it takes quite a bit of time in a week (2-2.5 hours) to handle updates.
And it would be nice to just automate it
|
You aren't supposed to watch it. Just type "emerge -uDUa @world" then check the output, if OK let it run and push it into the background.
ADDED: Type that enough time and it will roll off your fingers thanks to muscle memory.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2198
|
| Posted: Tue Jun 27, 2023 7:59 am Post subject: |
|
|
I'm guessing this could be aimed at someone maintaining several machines in a production environment, perhaps via a binpkg server. In that use case, you might just want to ensure all GLSA fixes get applied automatically, and be notified if something went wrong. That raises a question of how to handle non-GLSA updates. You might want to apply a month's worth of fixes to a test rig first, and once tested, apply them to production, or clone the test system to production, depending on how similar you make test and production.
Aside: this triggers a thought I keep getting: the default Gentoo setup isn't too good at systems management. For example, for many years I was missing emails from cron jobs and their ilk because I hadn't configured an SMTP server. There probably ought to be a Systems Management best practices section of the wiki. I've thought of kicking one off, but desist because it would expose my ignorance 
_________________
Greybeard |
|
| Back to top |
|
|
LabBrat
n00b
Joined: 21 Mar 2023
Posts: 4
|
| Posted: Wed Jun 28, 2023 6:37 am Post subject: |
|
|
| wrote: |
genlop works with elapsed time, no CPU time.
|
Thanks for the explanation.
I actually found a discussion where some users did the calculation with qlist and qlop.
However, I think this method also estimates elapsed time, and not CPU time 
| szatox wrote: |
What do you do during those 2 hours? Is it 2 hours per machine, or do you have a full DC worth of servers you handle during that time?
Also, do you want to actually make something usable, or is it mostly a coding exercise? Nothing wrong with doing code exercises, but those 2 things will probably benefit from different approaches.
|
Just to clarify, 2-2.5 hours is the combined time of doing updates for 2-3 times in a week on my personal laptop with Gnome desktop and a bunch of other large packages.
Also, please keep in mind that I am a total noob, and I've been using Gentoo Linux a bit less than a year
Although this project is part of Google Summer of Code 2023, I do wan't to make something usable and useful, hence here I am on the forums asking for feedback
| figueroa wrote: |
You aren't supposed to watch it. Just type "emerge -uDUa @world" then check the output, if OK let it run and push it into the background.
|
I am not watching it
And sure, updating is done with this command, but there are also other things to do before and after an update.
For example: sync portage tree, update portage itself (if needed) before updating @world, update config files after update, do clean up, restart some services or the whole system, reading elogs and news, dealing with errors and all that stuff.
| Goverp wrote: |
I'm guessing this could be aimed at someone maintaining several machines in a production environment
|
Yep, you are right
By default this project only installs updates from GLSA precisely because it is planned to be used on servers as well.
How exactly @world updates will be manged in this case I am not quite sure yet, I am planning to vigorously test it out on desktops and containers first and see how it goes.
When you say "cloning", do you mean like creating a stage4 tarball and overwriting the server with it? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54736
Location: 56N 3W
|
| Posted: Wed Jun 28, 2023 7:07 am Post subject: |
|
|
Goverp,
Gentoo in a production environment is maintained quite differently to a hobby setup.
At the production users that I'm aware of (not very many) use Gentoo as a roll your own binary distro,
Updates are build and tested outside of production, then the binary packages and matching snapshots ore released to production.
The production systems do not build their own Gentoo.
Think of it like building in a chroot for a much weaker system.
LabBrat,
Don't update portage on its own. Often its not possible.
That advisory message should be removed. I'm sure there was a bug for that several years ago.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2198
|
| Posted: Wed Jun 28, 2023 9:17 am Post subject: |
|
|
Neddy,
Indeed, I'd be amazed to see anyone doing production on per-box custom installs. But the model still applies - you typically need a development system (for new stuff), a test system (for pre-release testing) and a deployment system (where the production binpkgs sit), plus a backup or two. A managed way to easily propagate fixes and updates across such systems frees your staff for more exciting things such as preventing trojans, fighting malware, worrying about insider hacking, etc. etc. etc.
_________________
Greybeard |
|
| Back to top |
|
|
gtwrek
Tux's lil' helper
Joined: 10 Mar 2017
Posts: 112
Location: San Jose, CA
|
| Posted: Wed Jun 28, 2023 8:40 pm Post subject: |
|
|
| Quote: | Don't update portage on its own. Often its not possible.
That advisory message should be removed. I'm sure there was a bug for that several years ago. |
I've heard folks here recommend this a few times. But portage often detects a portage update is required, and explicitly suggests to do an | Code: | | emerge -av1 portage |
before any other updates.
Myself, I know just enough to get myself in trouble, I usually follow the advise that the gentoo developers tell me explicitly through the tool notifications. I do the above update before my world update. Is there a suggested alternative? |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3007
Location: Edge of marsh USA
|
| Posted: Wed Jun 28, 2023 9:03 pm Post subject: |
|
|
If portage wanted to emerge portage first during a world update, it would do so automatically. A recent update of a machine that's gone two months without attention built portage next to last out of 178 packages.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1990
|
| Posted: Thu Jun 29, 2023 2:17 am Post subject: |
|
|
| figueroa wrote: | | If portage wanted to emerge portage first during a world update, it would do so automatically. A recent update of a machine that's gone two months without attention built portage next to last out of 178 packages. |
It is still recommended to update Portage first because of a condition where a build may improperly record the location of the install binary that is placed in a temporary location when Portage is scheduled to update.
While rare, there have been occasions where failures may occur if a dependent build references the missing temporary tool location.
This is very unlikely, but a reason why Portage still recommends, but not requires, itself to be updated first. (EAPI failures on a neglected system may be another reason as well.) |
|
| Back to top |
|
|
toralf
Developer
Joined: 01 Feb 2004
Posts: 3942
Location: Hamburg
|
| Posted: Thu Jun 29, 2023 7:12 am Post subject: |
|
|
If glibc was updated, then the services and agetty processes at least needs to be restarted.
And (at least at my system) I need to run "setxkbmap -model pc105 -layout de -variant nodeadkeys" to have "y" and "z" at the expected keys. |
|
| Back to top |
|
|
ImErina
n00b
Joined: 10 Feb 2022
Posts: 51
|
| Posted: Thu Jun 29, 2023 7:22 am Post subject: |
|
|
I have had trouble updating my haskell packages, I hope there can be something that can really "understand" how to deal with complicated dependencies, such as that in the haskell repo.
Haskell-updater can work, but it still needs a lot of (potentially) unneeded rebuilds, and it really needs a lot of human labour and attention.
I hope there's a tool for easing the process. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20580
|
| Posted: Thu Jun 29, 2023 10:44 pm Post subject: Re: A tool that automatically updates Gentoo Linux |
|
|
| LabBrat wrote: | Hello everyone, I hope you are having a great time of day :wink:
I am coding a program to automate and simplify Gentoo Linux updates.
Wrote about it in detail in the blog: https://blogs.gentoo.org/gsoc/2023/06/25/gentoo_update-introduction/
It will be awesome to get some feedback on the idea :)
What features should it have?
What are some common problems that you are facing during upgrades that would be nice to address?
Any feedback/suggestion/contribution is welcome :D |
This seems like an ambitious project. Good luck!
| Quote: | | Code: | Alternatively, it can be installed with pip:
emerge --ask dev-python/pip
pip install gentoo_update --break-system-packages |
|
I'm immediately distrustful of anything that instructs me to:
a) download random things from the internet and simultaneously installing such random internet thing. I completely dismiss anything that makes such a recommendation incorporating root access.
b) move, at any speed, and "break" things.
Some additional concerns. How will the tool manage config file updates that must be addressed with user interaction, whereby failure to do so may cause a failure to boot, authenticate, or worse?
I delay upgrades of certain packages for various reasons and unspecified time. For example, I'm currently avoiding the glibc update mainly because I don't feel like rebooting that system. I regularly delay upgrading large or critical packages: web browsers, clang/llvm, gcc, sudo, pam, ssh, tmux, etc. Large packages usually for convenience; authentication related packages to prevent losing system access; and compilers to avoid unnecessary updates / long compile times if I don't plan to use them "soon enough."
My only major issue is in distributing binary packages and related config files, as well as the chroot in which the binaries are built. I don't know what a solution would look like -- other than perhaps "emerge-bin" -- but it would be seem less oriented toward enterprise use. That probably falls under the tedium and time category, with a complex solution that hasn't outweighed the tedium and time.
Next are issues that are primarily frustrating, but otherwise minor. I'd prefer to not deal with Python upgrades. Perl too -- any dynamic language really -- but it's been a while since perl caused me problems (likely perl-cleaner related). And the rare occasion when an ebuild is changed without a revision bump. I don't think those issues are addressable with an update management tool.
From a practical standpoint, going through post install messages is probably the biggest pain. eclean seems too broadly impacting. It seems to want to delete more than I prefer. I forget exactly, so I usually do it manually, and very infrequently.
| Quote: | | Code: | Here is the list of some tools that are commonly used during an upgrade:
[
eix, equery, emaint, euse, etc-update, dispatch-conf,
eselect, elogv, needrestart, eclean, eclean-kernel,
qcheck, revdep-rebuild, glsa-check, layman
] |
|
Of the tools I use in that list, no other tool is going to replace my need for them. eix is a faster method of searching rather than emerge -s. etc-update (or similar tools) shouldn't be automated. Just because I emerge a new gcc doesn't mean I'm ready to switch to it. Similalry for other packages which use eselect. Whether I use elogv or another tool, I still have to read the messages. Is glsa-check still relevant? Last I remembered using it, it rarely had anything to update. Software development in general has seemed to move toward the "install the latest version" solution rather than supporting older releases, so the latest version _is_ the security update. *sigh*
Honestly, if Microsoft supported a non-forced update solution, stopped collecting telemetry, and didn't push ads, I'd probably just go back to it (I jumped back to "desktop" Gentoo after Windows 10 Telemetry Edition).
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3477
|
| Posted: Thu Jun 29, 2023 11:07 pm Post subject: |
|
|
| Quote: | | ADDED: Type that enough time and it will roll off your fingers thanks to muscle memory. |
Man, it rolls off Ctrl+R even faster 
| Quote: | Just to clarify, 2-2.5 hours is the combined time of doing updates for 2-3 times in a week on my personal laptop with Gnome desktop and a bunch of other large packages.
Also, please keep in mind that I am a total noob, and I've been using Gentoo Linux a bit less than a year |
Everyone has been there at some time, fortunately it is not a terminal condition.
Anyway, I'm wondering what does your process look like.
On my machines emerge --sync is triggered by a cron job, so there is no need to do that manually or wait for completion when I'm ready to hit the button.
When I want to update, it's emerge -avuDN @world, wait for the work plan, inspect for obvious mistakes, accept and go about my business somewhere else.
Once it completes, etc-update, pretend to glance at the changed config files and zap them because too lazy to do a manual merge.
How to make it faster? Let config-protect save the new version in an alternative (well known) location and not prompt me to etc-update. Merging changes on every update does not make things less likely to misbehave than ignoring them, so I'd rather fix failures caused by not doing it than overdoing it.
Not doing it is free.
| Quote: | | For example: sync portage tree, update portage itself (if needed) before updating @world, update config files after update, do clean up, restart some services or the whole system, reading elogs and news, dealing with errors and all that stuff. |
Yeah, restarting services is something emerge could do, but someone decided it shouldn't. Looks like an opportunity for a new feature: detect init script, use it to figure out whether or not the service should be started, and restart it if it makes sense to do so.
Reading stuff does not seem automatable, in particular news are supposed to update sysadmin's knowledge. You can't have even the best tool learn you the changes.
Elog can be helpful when emerge fails, most of the time there's nothing worth paying attention too. And it is a good thing.
| Quote: | | Although this project is part of Google Summer of Code 2023, I do wan't to make something usable and useful, hence here I am on the forums asking for feedback |
Cool, do you have any defined expectations and constraints? Since you take part in a program backed by some organization, they may have put some restrictions on what you're supposed to deliver.
BTW, chances are that notifications (mail, irc, mobile app etc) could be portage's feature too. And there are hooks: https://wiki.gentoo.org/wiki/Handbook:AMD64/Portage/Advanced#Hooking_into_the_emerge_process |
|
| Back to top |
|
|
LabBrat
n00b
Joined: 21 Mar 2023
Posts: 4
|
| Posted: Wed Jul 05, 2023 7:07 pm Post subject: |
|
|
| pjp wrote: | | b) move, at any speed, and "break" things. |
Yeah I agree, it looks sketchy.
I will change this part to installation with Python virtualenv, this way it's not even installed in the system (still requires root access though).
The reason `--break-system-packages` is used is because since PEP668 new distros now implement stricter rules towards installing system packages with pip.
| pjp wrote: | | How will the tool manage config file updates |
For now there are 2 options - skipping altogether but notifying to do it manually after updates, and automerging it with `etc-update --automode -5`.
| pjp wrote: | | Is glsa-check still relevant? |
Yeah it's relevant.
I tested it successfully on old Gentoo desktop edition Docker containers.
Overall, thank you for such a detailed post!
| szatox wrote: | | Anyway, I'm wondering what does your process look like. |
1. `emerge --sync`
2. update portage if needed (`emerge --oneshot --update portage`). Although after the discussion above I am not sure if it's necessary...
3. `emerge --verbose --update --newuse --deep @world`
4. apply config changes, usually with `dispatch-conf`
5. read elogs with `elogv` and read news (`eselect news read new`)
6. run `needrestart` to see if anything needs reloading.
7. do clean-up once a week, usually with these 3 commands
a. `emerge --verbose --depclean`
b. `revdep-rebuild`
c. `eclean -d distfiles`
I don't follow all the steps everytime though. But at least once a week I will do all 7 steps.
| szatox wrote: | | Let config-protect save the new version in an alternative (well known) location and not prompt me to etc-update |
Yeah that's pretty smart, I totally agree with this approach.
| szatox wrote: | | restarting services is something emerge could do |
There is a tool for this - `needrestart`. It's available as an optional dependency in the updater.
| szatox wrote: | | Reading stuff does not seem automatable |
It's not.
But I was thinking that newest elogs and news can be sent to users via emails or irc chats, to get them as soon as update is finished.
| szatox wrote: | | Cool, do you have any defined expectations and constraints? |
Yep, main expectation is to have a working updater by the end GSoC2023 (early September).
By "working" I mean that it should be able to do both security patching and @world updates,
parse logs and identify common errors (if there are any), then create and send an update report via email, IRC or a mobile app.
One of the constraints is that it was decided not to modify Portage code(at least not during GSoC2023).
Apart from that there are no other constraints, as long as the updater is working |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5323
Location: Bavaria
|
| Posted: Wed Jul 05, 2023 7:40 pm Post subject: |
|
|
I'm following this with great interest ... and wish you much success. Please let me add one remark:
| LabBrat wrote: | | 2. update portage if needed (`emerge --oneshot --update portage`). Although after the discussion above I am not sure if it's necessary... |
We had times were it was necessary to do this ... and we had situations (after update of python) were it was not possible - only a "emerge -uDv @world" helped (our developers could tell more about these two situations) ... but ... as far as I understand your solution is meant for using it every day ... and if so, then we have only some emerges every day to do ... unlikely to get into a situation were an emerge of portage is necessary. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5323
Location: Bavaria
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
