autoslackpkg

Chuck56 · 11-26-2019, 11:59 AM

DISCLAIMER:

Code:

This is not intended to replace any tools already available in Slackware nor replace proper Slackware administration.

I used to do this...

Code:

slackpkg update
slackpkg install-new
slackpkg upgrade-all
review/modify *.new & *.orig files
mkinitrd_command_generator.sh
manually modify elilo.conf or lilo.conf (run lilo)
slackpkg clean-system
updatedb

Then I migrated to this to have multiple kernels available at boot...

Code:

slackpkg update
slackpkg install-new
slackpkg upgrade-all (except kernels)
review/modify *.new & *.orig files
slackpkg download kernel
installpkg *.tgz (kernels)
mkinitrd_command_generator.sh -k x.y.z
modify elilo.conf (copy files from /boot) or modify lilo.conf (run lilo)
slackpkg clean-system
updatedb

Now I do this...

Code:

autoslackpkg -m dialog

It's a script months in the making and working on my desktops, servers, LXC containers, & laptops. Take a look at the help screens before using. There are some required config changes so it can operate correctly.

CONFIGURATION MODIFICATIONS: (required)

Code:

/etc/slackpkg/blacklist
/etc/mkinitrd.conf
/etc/lilo.conf
/boot/efi/.../elilo.conf

If you're interested I posted a SlackBuild here...
https://www.go4it2day.com/news/autoslackpkg-0.8.html

I'm thinking about adding some config files and interested in feedback if you give it a go.

Lysander666 · 11-26-2019, 12:14 PM

Are you saying that this updates lilo.conf for you? It seems pretty impressive.

Chuck56 · 11-26-2019, 12:20 PM

Quote:

Originally Posted by Lysander666

Are you saying that this updates lilo.conf for you? It seems pretty impressive.

Yep! lilo.conf needs a few comments on specific bootable partition lines per the help screens.

Code:

# Linux bootable partition config begins
default=Gen4.4.186-smp
image=/boot/vmlinuz-generic-smp-4.4.186-smp
  initrd=/boot/initrd-4.4.186-smp.gz
  label=Gen4.4.186-smp
  read-only #4.4.186-smp
image=/boot/vmlinuz-huge-smp-4.4.186-smp
  label=Hug4.4.186-smp
  read-only #4.4.186-smp

upnort · 11-26-2019, 01:28 PM

Support for GRUB?

Chuck56 · 11-26-2019, 01:32 PM

Quote:

Originally Posted by upnort

Support for GRUB?

Nope, I'm not GRUB compliant yet! Not out of the question, just not something I've needed to use.

Chuck56 · 11-26-2019, 04:37 PM

Here's the overview help screen, "autoslackpkg -h overview"...

Code:

overview help

autoslackpkg automates the use of slackpkg. The script expects to be run as
the root user. It also expects specific modifications to blacklist,
mkinitrd.conf, efi.conf & lilo.conf.

Extensive help screens with examples are available. To see usage help
run (autoslackpkg) without options or arguments. Usage help also is
displayed if there is a script option or argument error.

When run with the -h option and a valid argument (autoslackpkg -h overview |
blacklist | elilo | lilo | mkinitrd) the script provides help.

When run with the -m option and a valid argument (autoslackpkg -m dialog |
batch) the script runs in either dialog mode or batch mode. Dialog mode
is a hands-on, interactive mode. Batch mode runs without user input.

When run with the -s option (autoslackpkg -s update | install-new |
upgrade-all | clean-system | install-kernel | remove-kernel | new-config)
the script only runs a specific section of the overall script.

The script maintains multiple kernels and manages EFI & LILO setups
(not GRUB yet). The default boot kernel is changed to the most recent kernel.
In the unlikely event the most recent kernel is not functioning properly the
system can be rebooted with the previous kernel.

The script runs in 2 Phases. If not installing a new kernel then autoslackpkg
runs both Phase 1 & Phase 2 in succession. If a new kernel is installed then
only Phase 1 is run & reboot is required. After reboot, rerun autoslackpkg
then Phase 1 is skipped & only Phase 2 is run.

Phase 1 includes:

  1) slackpkg update
  2) slackpkg install-new
  3) slackpkg upgrade-all (see blacklist help)
  4) new kernel download & installation (see blacklist help)
  5) mkinitrd for new kernel (see mkitrd help)
  6) EFI system new kernel management (see elilo help)
  7) LILO system new kernel management (see lilo help)

Phase 2 includes:

  1) slackpkg clean-system
  2) EFI system old kernel management (see elilo help)
  3) LILO system old kernel management (see lilo help)
  4) run updatedb
  5) slackpkg config-new
  6) find /etc *.new & *.orig

Here's the usage screen, "autoslackpkg" without options or arguments...

Code:

Usage: autoslackpkg [-h|m|s|v] [argument]
  [-h] help    - requires argument
                 overview | blacklist | elilo | lilo | mkinitrd
  [-m] mode    - requires argument
                 dialog | batch
  [-s] section - requires argument
                 update | install-new | upgrade-all | install-kernel
                 | clean-system | remove-kernel | new-config
  [-v] version - release version

enorbet · 11-26-2019, 07:45 PM

I'm really not trying to rain on anybody's parade. I'm just curious so I have to ask...

"Are you guys trying to automate package installation newcomers to Slackware?"

I ask this because when I first adopted Slackware as my Main but kept testing other distros, I often found myself trying to make them behave like Slackware but I soon found that was most often an exercise in futility. It was better to change them as minimally as possible at the very least for just testing despite my sometimes extreme frustration at not being allowed to do things manually or being allowed, with some workaround, but breaking things along the way. Much of the power and extreme low maintenance of Slackware is a direct result of NOT automating, where an admin knows nothing is happening behind his back and all processes are simple, even singular so any difficulties are easily traced back just one step. Why introduce complexity? If that's what you prefer, why choose Slackware?

Chuck56 · 11-26-2019, 09:46 PM

Quote:

Originally Posted by enorbet

... "Are you guys trying to automate package installation newcomers to Slackware?" ...

Newcomers would be wise to not use this script IMHO. My project started off automating the highly repetitive task of updating -current. The side benefit is it works well on 14.2 as well. It will fail without a properly functioning slackpkg, fully populated & customized mkinitrd.conf and properly commented lilo/elilo.conf files. The system needs administation before using this script. After setup it is kinda point and shoot.

I manage 10 Slackware systems locally and 2 Slackware systems remotely. This script standardizes how I upgrade them all.

enorbet · 11-26-2019, 10:14 PM

Thank you for your prompt and thoughtful response, Chuck56. If you don't mind I'd like to follow up with another question. Have you used some distro other than Slackware where you liked automated updates? I'm looking to discover what made you desire such a fundamental alteration, what tradeoffs you considered, and how you concluded the benefit is worth the cost.

Chuck56 · 11-26-2019, 10:43 PM

Slackware was my 1st and only distro since 2005. I've never needed to use another distro. My plan is to stick with one distro and learn to run it well.

I don't see my script as a fundamental alteration of anything other than the avoidance of a highly repetitive process. I had to learn what needed to be done and memorialize my learnings into the script. I don't know about others but many times I have cobbled together a complex solution only to find when it fails I struggle to get it working again. My documentation is getting better but is never enough. Scripts on the other hand have served me well in these situations.

For example I run a mirrored pair of servers that run DRBD between them and support numerous LXC containers. The concept is under normal conditions the containers are balanced between the servers. If I need to upgrade the servers I migrate all the LXC containers over to 1st server while the 2nd server is down for maintenance. The whole process of managing DRBD between the servers and starting/stopping the containers is a complex suite of scripts. It's well documented and it has been upgraded/modified a few times over the years.

Hope that helps.

enorbet · 11-27-2019, 11:16 AM

Thanks again, Chuck56. I consider the major fundamental difference between distros to be package management which is why I've asked all this. Now I have a clearer ide that you'ver simply developed a workable tool that was motivated by the work you do, rather than any other distro's stab at convenience. Thanks... makes sense now.

bassmadrigal · 11-27-2019, 01:28 PM

I don't think the intention was to make upgrades "automatic" like setting a cron job and having Slackware update at 3AM everyday. I think it was more to just script the commands he would normally type when updating the system to allow him to just run one command instead of all the individual ones needed to use slackpkg and finalize the system after those updates.

Seems to be a similar automation that slackpkg allowed compared to manually downloading and upgrading/installing packages from your favorite mirror...

enorbet · 11-27-2019, 02:13 PM

Quote:

Originally Posted by bassmadrigal

I don't think the intention was to make upgrades "automatic" like setting a cron job and having Slackware update at 3AM everyday. I think it was more to just script the commands he would normally type when updating the system to allow him to just run one command instead of all the individual ones needed to use slackpkg and finalize the system after those updates.

Seems to be a similar automation that slackpkg allowed compared to manually downloading and upgrading/installing packages from your favorite mirror...

Agreed, bassmadrigal, I knew that going in. I don't use nor even like the idea for myself of using slackpkg at all for myself. I consider any extra time in doing each install manually, one step at a time, pays dividends in immediately seeing where any difficulties are and never having to look further back than that one isolated step. This thread merely triggered my curiosity as to why people embrace multi-step automation of package management since this thread pointed out that even that automation is becoming automated which signaled some growth in this direction to me. I don't see myself ever adopting such automation but I do like to keep up with how Slackware is customized and how it fares against similar functions in other distros and why people would choose those departures from basic KISS methodology. In this case I can easily see how it is very different keeping one box up to date than several. There is nothing to be gained by dogged repetition once you know it works properly and simply requires being deployed. After one instance, it's effectively done. That it must be repeated several times is mere busy work at that point. As I said... makes sense, now.

Chuck56 · 11-27-2019, 02:41 PM

Quote:

Originally Posted by bassmadrigal

... Seems to be a similar automation that slackpkg allowed compared to manually downloading and upgrading/installing packages from your favorite mirror...

Pretty much how I view it. The side benefit for me was learning to manage multiple installed kernels and automate the EFI/LILO changes. I ended up becoming much better informed about slackpkg, slackpkgplus, mkinitrd, mkinitrd_command_generator, elilo.conf & lilo.conf.

I have a renewed appreciation for the smallest fraction of what our BDFL deals with maintaining Slackware.

Tonus · 11-27-2019, 04:49 PM

That looks great. I might use it more for people I install Slackware for (I don't want to bother with any crappy distribution nor Microsoft outside work)! Looking forward to grub support...

For myself, I keep my personal copy of the package tree with custom rsync script derived from Alien Bob's and upgrade by hand.
Still, I am lazy and use slackpkg after that to check for *.new files...