Wednesday, May 23, 2018

I am a big fan of Bacula. It is an enterprise-class backup system with a huge amount of flexibility when it comes to it's setup and the setup of the backup jobs. It was built to handle and manage tapes and has the most flexible way of selecting and choosing which directories and files to backup.
I've since moved on to Bareos, mainly because they were adding features and functions to the backup system that moving with the times. The decision to build a web-based user interface also mae me gravitate to their orbit.
Recently, I've been setting up Bareos with MySQL version 8. The main takeway when working with MySQL version 8 is that MySQL now made some default choices to be more of a secure variety.
Which leads to problems installing Bareos. Basically, the scripts written to set up the database took advantage of the lower security requirements of the previous versions of MySQL.
So I set about figuring our what to change and where. The scripts that were setting up the database were in /usr/lib/bareos/scripts/ . There were 3 scripts, create_bareos_database, make_bareos_tables and grant_bareos_privileges. All these scripts called another script called bareos-config-lib at the start of the scripts which provided the base functions and parameters. Running the scripts would throw up an error. I needed to see what was the command executing that was producing the errors. In this case, the commands were being provided through the bareos-config-lib script which itself called other files and scripts.
After poking around, I decided to think like an open source programmer, looked at other files in the same directory and started reading the code for clues. I found another script called bareos-config which took in a parameter. The parameter was the functions called in the bareos-config-lib. So the bareos-config-lib file had a function called get_database_grant_privileges. So to see what function provided, I executed bareos-config get_database_grant_privileges which then provided the output of the commands that executed the function. bareos-config get_database_driver will tell me what database Bareos is configured for. bareos-config get _database_password provides me with the database password used by Bareos to access the database. And so on and so forth.
This is a sign of a mature open source project. A tool exists to validate input or commands, created for the use of other future programmers. Now I know what my problem is exactly and I can fix it.

Friday, August 11, 2017

It's seems that I post only to complain about Systemd. I have tons of other articles in draft but only the ones about systemd drives me hard enough to complete them and post them. My other post on SystemD took some time longer but this was written in record time.. So much so that I write as a form of release or therapy in the face of all the roadblocks systemd has put between me and what I want to accomplish.
Systemd is a way their developers of saying to all the guys who have been doing Linux longer than them, "Sorry, what you knew then, is worth nothing now. We are the next generation and we are changing the game." Typical talk from the young who thinks they know it all. It gets worse when you think they are also saying, "We saw something better and we are doing it that way." when what they really saw was Linux through a terminal session in Windows or a Mac. The behavior of pushing people up the stairs, even when you don't really know whats at the top. All they see is light but it could just as well be a cliff.
While the dev seemed to claim they were seeing the light, it's that odd that one of the main things systemd did was blind others to what it was doing by making other people jump hoops through journalctl. It kicked syslog to the curb even though it didn't do everything syslog did. Being opaque was the order of the day.
Systemd is a solution looking for a problem. Rather than building a layer on top of work done before, they decided to start over, which was ok but then said "It's my way or the highway." and "We'll redo the tools you made before but they'll only work with our stuff, our way." It doesn't necessarily improve anything, only just for completeness of control when it's just masking "I can't be bothered interfacing with anyone else's stuff". Systemd has a bully mentality and it probably rubbed off from the people who developed it. It also has a Windows mentality of "(more) complexity is the solution" and "security is what we do later". Which telling of where the developers get their ideas from.
Basically, RedHat, who is funding this realizing this or not, gains the most. They can't control Linus and his kernel team. So, why not build a wall around the kernel and forcing everybody to go thru systemd to get daily things done. Linus can do what he wants in the kernel, RedHat controls the doors leading to the kernel. And a knock-on effect for them is more people require retraining because all that knowledge accumulated is worth less now with systemd.
Let's get this straight, systemd works when it gets out of the way, like in desktop distros. I run Mageia and it's wonderful. I don't have to deal with it directly. But when it makes previously simple tasks complicated forcefully, then we have a problem. If it changes stuff while I am configuring other things and claims "but I told you so in the logs that you have to enter 4 parameters to make it readable", we have a problem. Look, things aren't perfect and improvements are always welcome. And Linux people love to learn new stuff. But it's hard to compare when the first thing done is say "I'm the only one competing." And being forced to learn is always a turn-off.
But I guess we are living in times when bullying is ok.