Package managers: APT vs DNF

 

Here we are looking at the package managers 'apt' and 'dnf'. Both are modern and powerful tools for searching, installing, and managing the applications and packages installed in their respective Linux derivatives. Both share a lot of common commands as well, so it is very familiar to work with either. 

Not mentioned in the video, but a wonderful feature of open source software, is both work in most distributions and are not 100% relegated to those specific distros that ship with each respectively. That said, the package manager is a powerful component of a distribution, and I feel it is worth trying to learn the default tooling for each distribution one really wants to spend time with.  

This effort is part of a series I have rolling around in my noggin around package managers and their importance to the adoption of Linux by most people. I strongly feel that while they predate, and perhaps even inspired the concepts of App stores or Google Play used by mobile devices, not a lot of credit is really given to them. What makes package managers and the relevant repositories even more powerful than app stores is, because they run as commands, they can be scripted. Scripting allows more ease in management by sysadmins and others who need to work with a large fleet of devices. 

Before App stores, Linux was always safer then Windows primarily because software was curated for the distribution of choice. Installed packages, so long as they were coming from the package manager and the associated, known-good repos, had, and continue to have, way less risk than just going to websites and downloading software to run on a Windows PC. Package managers are faster, more reliable, and safer than what many people use to install and manage software on their computing devices, making learning them very important. 

Hopefully with just a few simple commands like 'apt update', 'apt upgrade', 'dnf update', 'apt install <whatever package you want in the repo>', and 'apt remove <installed package you do not want>', etc. new users can better take advantage of Linux and open source tools. 

More reference:

https://docs.fedoraproject.org/en-US/quick-docs/dnf-vs-apt/

https://en.wikipedia.org/wiki/APT_(software)

https://en.wikipedia.org/wiki/DNF_(software)

Minio in an Alpine Linux VM

 

Alpine is a really nice, really light Linux distribution that is often use as the base for a lot of containerized applications. This video demonstrates how to create an appliance-like VM with a minimal Alpine install to run Minio from boot. 

All of the steps aside from running the start up command using cron are in the documentation below. It is truly very simple to get working in Alpine if you just need something simple to act as an S3 object store with HTTP/HTTPS file sharing capabilities. 

A couple of mistakes in the videos are there because by copying the commands from the documentation I forgot to adjust the start up and cron commands to the directory we gave it. This is why at minute 5:50 I am checking the wrong directory and the new directory is shown (miniodata vs minio). Overall it is pretty simple and perhaps the mkdir command can be skipped depending on your preference.

References:

For the basic setup on Linux:
https://min.io/docs/minio/linux/index.html

For Debian/Ubuntu or RedHat/CentOS/Fedora installs:
https://min.io/docs/minio/linux/operations/install-deploy-manage/deploy-minio-single-node-single-drive.html 

If there are any questions, please let me know in the comments. 

Upgrading Nextcloud in Docker

 

This is a quick post on updating and maintaining a Docker install of Nextcloud. I have had my install pretty much untouched since I first put it up about a year or two ago. The whole time it's been fine, but I heard about performance improvements in later versions and have begun the process of upgrading the service. 

Here are some steps to check for. 

Based on my previous restore experience, I know that going from one version of docker to the next can sometimes be version dependent. What has worked in managing the upgrades is to upgrade one version at a time. 

To do this, first check what Nextcloud describes as the newest version. Enter the system as the 'admin' user, go to 'Settings' -> 'Overview'. A screen like below should show.

Nextcloud will give a few suggestions of areas to make your instance more secure or highlight any issues (this is a private instance without HTTPS, as noted, and without a lot of the Calendar and other apps), and it will display what the next version is. 

That next version will be the upgrade target for the Docker instance.

In your host, you can first pull the new Docker image of Nextcloud by running:

sudo docker image pull nextcloud:<the target version from the UI>

This will save some time in the upgrade.

Next make sure everything is saved and no one is using the containers. Stop the containers with:

sudo docker stop <nextcloud container name> <nextcloud DB container name>

In my sample docker-compose reference the command would look like:

sudo docker stop nxtcloud nxtclouddb

Then modify the docker-compose.yml file with the new image specified just downloaded. For example 25.0.3 shown below. 

app:

image: nextcloud:25.0.3

container_name: nxtcloud

restart: unless-stopped

  ports: 

  .....

Once changed bring up the containers again.

sudo docker-compose up

Here I omit the -d for running in the background. This offers a terminal view of the upgrade similar to below.

Give that a few minutes, and then the Nextcloud should be upgraded to the new version. 

To ensure the containers can be run in the background without an active terminal, stop the containers again, and re-run the sudo docker-compose up -d with the -d flag.

Some more information about Nextcloud is throughout the blog - just click on the Overview page or search by the Nextcloud tags on the right-hand side. 

For more information about the reference docker-compose to get started with it and a MariaDB instance check out the source in GitHub.

Save USB ports using Logitech Devices in Linux

A new find. I was watching a tech reviewer video of some Logitech stuff. I am a huge fan of Logitech especially on Linux as seems to have the best driver support for both there unifying receiver and bluetooth. In the review, they mentioned that the support software for Logitech can allow a single unifying receiver connect multiple devices. OMG!

Googling quickly about how to accomplish the same task on Linux, which Logitech doesn't officially support with their software, again the community came to the rescue. I stumbled upon Solaar!

Solaar allows for device management of Logitech stuff with a simple GUI and easy install. In PopOS - I imagine Ubuntu as well, likely Debian too - you can simply run 'apt search solaar', and then install with a 'sudo apt install solaar'. 

Launch the application from the application center - in my case hit the Window key and just type 'solaar'. Like any Linux software with a GUI it should appear.

To combine the devices connected on a single receiver you can simply start a search. There will be a warning that if the devices are connected you need to unplug them for them to appear. Unplug, re-plug the 2 USB receivers. 

The devices and their respective receivers should appear. 

To pair a new device click on a single receiver. Click 'Pair new device'. 

Unplug the mouse receiver or keyboard. 

The device will start broadcasting, and the other receiver will pick it up. If the mouse is removed, there is a confirmation button that needs to be clicked. Tab to the 'Confirm' button from the keyboard and press 'Enter'. 

At this point you should have 2 Logitech wireless devices on a single receiver, thus saving a USB port in Linux, or perhaps saving the need to get a new receiver in case one is lost!

More info on the project: https://pwr-solaar.github.io/Solaar/

Backing up MongoDB

Explored in previous posts and videos, MongoDB is a great way to store information without a schema. All of the information is stored in a JSON like format called BSON which essentially are documents, but similar to a SQL Database the data cannot be directly read on the host system. 

I was interested in learning some more about how to backup the files. Turns out that MongoDB provides a dump tool similar to MySQL called mongodump and mongorestore. 

To get started one can run the following command on their host system or container. If you used the MongoDB Docker image, the mongodump command can be run inside the container directly. 

Local Run

mongodump -u=<user> -p=<password> --authenticationDatabase=admin --db=<database to download>

The part '--authenticationDatabase' is important. On the MongoDB container the users allowed to access the database are specified are in that 'admin' database on the Mongo instance, and it must be defined in the mongodump command for the connection to be successful.

Similar to mysqldump, the mongodump command can also be used from a remote host.

Install the MongoDB Command Line Database Tools on the remote host. They offer the tools for Windows, Linux, and MacOS. 

*Note on Fedora 36, using the RedHat/CentOS 8.0 package worked. *

Modify the previous command to the below:

Remote Run

mongodump --host=<Domain/IP> --port=<Mongo service port - default is 27017> -u=<user> -p=<password> --authenticationDatabase=admin --db=<database to download>

Assuming a connection can be made all of the database files and relevant metadata will come down to the directory where the command was run. A successful run will look similar to the below. 

Once complete you will see a directory called 'dump' with the database(s) listed as directories inside. 

To specify the output location on the local system (the system being used to access and backup the MongoDB instance) you may use the '-o' or '--output' flag. 

Remote Run | Specify Download Location

mongodump --host=<Domain/IP> --port=<Mongo service port> -u=<user> -p=<password> --authenticationDatabase=admin --db=<database to download> -o=<directory location>

Restoring data from a Mongodump

The companion utility to mongodump is mongorestore. Mongorestore works similarly to mongodump, but the user specifies the db and the back up files. 

mongorestore --host <Domian/IP:Port> --authenticationDatabase=admin -u <user> -p <password> -d <db to restore> <backup folder location>

One additional tip: 

If the container was installed using the same docker-compose from the PHP and MongoDB tutorial, the port for the MongoDB Instance isn't exposed on the local system. This is good from a security standpoint. The companion web server accesses using the hostname from the private Podman / Docker network. To access the container host from the physical machine you need to use the IP address of the MongoDB container itself.

Using either Docker or Podman, run the inspect command to check to find the Network information. 

sudo podman inspect <container name or ID> | grep "IPAddress" OR
sudo docker inspect <container name or ID> | grep "IPAddress"

Additional information:

Information about using mongodump

Information about using mongorestore