Very useful yay commands for maintaining Arch-based linux distributions

About yay

yay commands using updates based on time, instead of version numbers, uses both official repository and aur simultaneously, loops sudo to prevent authenticating more than once, saves to config

Yay, Yet another Yogurt. is a command line tool for accessing the AUR (Arch User Repository) and managing packages on Linux Arch and Arch-based distributions (see: Manjaro and many more..). Written in Go, yay has been tried and tested for many years and remains my go to package manager for any distribution that supports use of the AUR.

That said, many users find themselves in deep water when they’ve accidentally allowed their packages to come into a “partially updated” state. This most often happens when people bounce from repository to repository trying to scratch a tiny itch (like say, from stable to testing or, more likely, from testing back to stable). These kinds of transitions need careful steps to be taken to be performed smoothly. And, even then, you should really have a good understanding of your operating systems before proceeding.

Either way, it’s possible, after a while or even heavy use, that you find yourself in a situation where your packages are in a “partially updated” state. And, of course, we all need to do a little spring cleaning, from time to time. The following yay commands will help you immensely.

Full System Update Using Yay  Commands

Copy

yay -Syyu

Lets break this down. First, we have -Syyu.

Here, -S tells yay we want to synchronize our package list with our upstream (defined in pacman.conf), an obvious step in looking for updates.

Next we have the repeated -yy this tells yay to get a fresh list of packages, and the second iteration tells yay to get a fresh list of packages even if our current list is not out-dated. This yay command should not be abused more than once a day.

Finally, we have -u, which predictably tells yay to upgrade any out-of-date packages. But, we still have these other toggles and why do I use them? It’s because I use the AUR.

Thise particular yay command is useful anytime you notice you have a package that has a version number that is abnormal.

yay shows packages with unusual version numbers

And here’s why. --timeupdate the timeupdate toggle tells yay to ignore version numbers and look for the date and time the latest PKGBUILD was pushed upstream to judge whether an upgrade is available for a package or not. This is critically important if you happen to get a package that’s orphaned often or otherwise has inconsistent version numbers.

Combined upgrade is exactly what it sounds like. Adding the toggle --combinedupgrade tells yay to upgrade packages from both the official upstream repository, as well as from the AUR, at the same time.

This one is simply handy. --sudoloop keeps sudo in play, in the background, during the various PKGBUILD processes, so that you don’t have to keep authenticating during longer package builds.

--save, of course, saves the toggles you used this time as the default toggles, for the next time you run any yay commands. It will assume these options, unless you specify otherwise.

Yay commands for maintenance

Due to the nature of the AUR, lint can tend to get left all over your system. Be it an orphhttps://www.grayhatfreelancing.com/aned package, or a PKGBUILD changed dependencies or requirements by the time it or some other package was removed. Here are some useful yay commands for maintaining the software on your system.

Copy to Clipboard

The yay command yay -Qt comes in quite useful when you’re cleaning your system of software lint. Or, in other words, software you may have explicitly installed, but can safely remove.

The -Q toggle stands for Query. You’re telling yay to query packages installed on your system.

The -t toggle stands for dependency test. This toggle for both pacman and yay will search for packages are that not required or not optionally required by any other installed package. Hence, they can safely be removed. If you’re feeling frisky, you can use the -t toggle twice, to include packages that are optionally required by installed packages. These can safely be removed without breaking any installed package, but you may lose some functionality if they’re not present.

2021-10-16T09:11:39-04:00October 12th, 2021|Categories: Engineering|Tags: , , , , , , , , |

systemd-backlight fails to start

So, for years now, some of us have been plagued with this nagging systemd-backlight services failure that’s mostly benign. But, anytime you run systemctl status you’d be returned with a status of degraded because this silly systemd-backlight service was just not wanting to cooperate. For most of us, it simply failed to store out backlight brightness level after reboot. But other’s have had more serious issues.

I’ve seend this issue crop up on multiple linux distributions in various forms. So, be clear, it was affecting me most recently on Linux Manjaro (my daily driver). I have an MSI laptop, with an AMD Ryzen CPU and AMD Radeon GPU. As well, my backlight has always worked and been fully adjustable.

The only negative side effect I suffered was that my system would never remember my brightness settings across a restart. Which is not really a problem at all, in fact, it’s been helpful more than once. But, others have not been so lucky. So, here’s how you fix this annoying bug.

You’re going to need to edit two different files, as you’ll see during remediation, there’s more than one problem going on here. First and foremost, if you’re seeing the [email protected]:acpi_video0 status failed lets start by attacking that issue.

I’m not certain, but the bug tracker sounds like it’s a race condition during discovery, that is solved if you specify your acpi_backlight module at boot. This is what worked for me.
So, lets open /etc/default/grub in our favorite editor and find the line GRUB_CMDLINE_LINUX_DEFAULT.

Append the acpi_backlight kernel option by adding acpi_backlight=vendor. Please note, there are three possible options here: vendor, video and native. If one doesn’t work for you, you’ll have to try the others. For my amdgpu vendor worked for me, which is where I ran into another issue.

Edit grub config

Coming back to that, after you’ve saved your changes, go ahead and run update-grub and reboot. Hopefully, this fixes your issue. For me, I started seeing errors with [email protected]:amdgpu_bl1.
It was telling me I had an invalid Type variable in my systemd file.

To fix this, I edited the /usr/lib/systemd/system/[email protected].service file and changed the line Type=idle to Type=oneshot. And whala! No more errors. Now when I run systemctl status it always returns running.

systemd-backlight

/usr/lib/systemd/system/systemd-backlight

Check here for some scripts that might work for you, if you want a more comprehensive solution (provided that your issues match the problem mentioned here, mine did not).

Note that one other thing I did was to quit relying on KMS (sigh), as it’s been causing me other race conditions at boot. So, I added graphics module to /etc/mkinitcpio.conf. If you’re using something like a hybrid setup that requires bumblebee or what not, I do not recommend this. But, I specified on the MODULES line MODULES=(amdgpu). And of course ran mkinitcpio -g afterwards and reboot.

systemd-backlight add gpu's kernel module

/etc/mkinitcpio.conf

It was depressing for me, personally. Because I’ve always had to deal with that Intel+Nvidia bumblebee cluster fuck. And I was greatly looking forward to letting KMS do it’s thing. But, race conditions are hard to nail down and I’m not going to be annoyed until someone gets around to it.

2021-09-30T00:10:21-04:00September 29th, 2021|Categories: Engineering, Random Fixes|Tags: , , , , , , |

A Perfect WordPress Deployment using the Terminal

How to Manually Perform a WordPress Deployment

I’m going to walk you through a WordPress deployment, using only the terminal. This is mostly because I need to put some content up here. And, once upon a time, this used to be one of my staple articles. Nothing has changed, really. But, I will reiterate the fact that you really should know how to do things manually, because you start plowing ahead and automating them.

Automation is good, it’s absolutely necessary, even. But, when things break, it’s best that you’re able to figure it out how it happened. And, the easiest way to obtain that information is, sadly, the hard way.

WordPress being so evolved.. Please do not expect a WordPress deploy to be something you can’t handle. Deploying WordPress is very straightforward. So, let’s get started.

virtual guest linux debian in a vagrant
Linux Debian 9 as a vagrant guest

LAMP: Linux, Apache, MySQL and PHP

WordPress runs very well on almost any web server. But, for the purposes of sticking to the documentation, we’re going to use Apache (not that I always stick to the documentation, mind you). You should familiarize yourself with a “LAMP” deployment anyway, it’s pretty much what powers the entire internet. Please note that MySQL is often replaced with either MariaDB or Percona Server. I won’t go into the differences here.

Go ahead and SSH into your web server, update your software repository and do a full system upgrade. There’s no reason to deploy LAMP without the latest patches. I’m using debian, so your commands may be slightly different for these types of things. Refer to your distributions handbook, if you need to.

sudo apt update
sudo apt dist-upgrade
sudo apt install apache2 mariadb-server php-fpm

Enable the Necessary Apache Modules

Hah! Before, that required us grabbing a whole lot more packages than it does these days. But, don’t worry! We will still need to go get various PHP libraries for our WordPress deploy to be successful (specifically, for it to interact with mariadb). Still, you don’t need to do anything else there on Debian, unless Apache was previously configured with libapache2-mod-php. Then go ahead and issue the following (unexplained):

sudo a2dismod php
sudo a2dismod mpm_prefork
sudo a2enconf php7.3-fpm (at time of writing, 7.3 was stable)
sudo a2enmod mpm_event fcgid cgi proxy_fcgi setenvif rewrite
using terminal to swap apache modules for a manual wordpress deploy
Configure Apache

There’s plenty of other Apache modules that are beneficial for WordPress, but we’re just doing a deploy right now.

Prepare MariaDB for Production

I’m pretty sure that we all knew MySQL shipped with insecure defaults for many years. So, I have no idea, why this tradition has carried through to MariaDB. But, it’s my opinion, that we should damn not be having to still do this bit here. But, set a root password for the SQL db. And, disable remote access. Run ‘mysql_secure_installation’, press Y to everything and set a password.

Install the Minimum PHP Requirements

As I just said about Apache, there’s also plenty of PHP libraries that will benefit WordPress, but they’re beyond the scope of this walk through. So, we’re only going to grab what WordPress requires to install without complaint, as well as what is required to return a green health check.

sudo apt install php-mysql php-gd php-bz2 php-curl php-zip php-xml php-gmp php-intl php-mbstring php-xmlrpc php-token-stream php-mcrypt
manual wordpress deploy, installing required php modules
install php modules

I, honestly, don’t know what to tell you about PHP modules. Depending on your linux distribution, your PHP package is going to come with different modules. There’s really no telling what was bundled with it and what wasn’t. If you’re on Debian, this will get WordPress up and running, at least. But, on others, the packages will be named differently anyway. So, try to reach this minimum.

WordPress Deployed from Terminal

On Debian, Apache’s default “webroot” is in /var/www/html . Your “webroot” may be in a different location. If you don’t know, check your Apache configuration. It should be located in /etc/apache2 or /etc/httpd – The filename would either be apache2.conf or httpd.conf

Anyway, back to manually WordPress deploying from the terminal. I’ll have to clean this up later. But, for now, I’ll just finish what I started. Jump on over to webroot, grab the latest version from wordpress.org and extract it. All that’s left after that is to create a user for “MySQL”, set permissions and run the installer.

cd /var/www/html
wget https://wordpress.org/latest.zip
unzip latest.zip
quite literally deploying wordpress into a folder, out of compressed zip file
extract wordpress

Note: this next part you can ignore. What I am doing is deleting my webroot and moving the folder wordpress extracted to in place of my webroot. If you extracted wordpress into ./html/ then you don’t need to do this.

rm -rf ./html/
mv ./wordpress/ ./html/

Create a MySQL Database, a MySQL User, Marry Them

Now we need to create a MySQL database. Create a MySQL user and grant it privileges to write to the database. Then, fix the file permissions and we’re done with the terminal (the website is technically up, a that point.

mysql -u root -p (perhaps prefix with sudo, if you're not root)
mysql> create database wordpress;
mysql> grant all privileges on wordpress.* to 'wordpress'@localhost identified by '[email protected]';
mysql> flush privileges;
mysql> quit
grant all privileges on WordPress Deploy to Deploy@WordPress identified by 'ASSWORD'
Identified by assword?!

Let’s set some privileges, first give the user that runs Apache ownership of the files. Then set the directories to read/write, read/write by Apache’s user and group. Finally, give the files read/write to Apache’s user and read/execute to everyone else (since php-fpm needs to read and run them).

Fix File Permissions and Be Done!

chown -R www-data:www-data /var/www/html
find /var/www/html -type d -exec chmod 755 {} ;
find /var/www/html -type f -exec chmod 644 {} ;

At this point, we really need to bust out our browser and complete the install, so we can prevent about a billion zombies from hammering away at our install script and owning the box (just log password attempts on WordPress for a week and you’ll see what I mean). So get your browser out and finish this bitch off! You’re done.

Good luck. Have fun! And, next map. If you’d like this handled for you, drop me a line at Gray Hat Freelancing!

wordpress initial configuration - final step of wordpress deployment
Porky Pig

FIN – Our Job Here is Done

There’s plenty more to do. Especially from a security standpoint. I can tell you right now, our file permissions are decent but not perfect. There’s optimizations that need to be made or your blog could become a zombie in a DDoS, etc.. But, those are for another article. For now, enjoy the WordPress deploy!

wordpress has been deployed - hello world
Hello World!
deploying wordpress - do the speak english in wordpress deployment?
Self-explanatory
wordpress database configuration - almost done with wordpress deployment
@ssword
2020-07-24T10:32:56-04:00April 10th, 2020|Categories: Engineering|Tags: , , , , , , , , |
Go to Top