SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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...
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?
... "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.
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.
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.
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.
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...
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.
... 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.
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...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
