Deploying your company's app

Not all software comes from dnf or apt. Sooner or later, your own company's developers hand you a program: “Here's ourapp, can you put it on the server?” Doing that well uses almost everything in this course: folders, users, permissions, links, systemd and logs. This lesson is the capstone.

Why not just put it anywhere?

You could leave ourapp in your home folder and start it by hand. Then you go on vacation, the server reboots, and nobody knows where the app lives, how to start it, or which files are safe to back up. A tidy layout means any admin, including future you, can find everything without asking.

• Not /usr/bin: that belongs to the package manager (Linux Basics, lesson 7).
• Not a home folder: people leave, and home folders get deleted.
• Yes /opt: the standard place for add-on software that isn't part of the distro. The rule is /opt/COMPANY/APP, so all your company's apps sit together and never clash with another vendor's “ourapp”.

The /opt family

The filesystem standard splits an add-on app into three folders, by what kind of file it is. This is what makes backups and upgrades easy:

Now the backup plan writes itself: back up /etc/opt and /var/opt (lesson 8), and the program can always be reinstalled from its release file. Some vendors cram everything, settings and logs included, into /opt/vendor/app. You'll see both styles in the wild. The split version is easier to manage.

A service account

The app should run as its own user, never as root and never as you. If someone finds a bug in ourapp and takes it over, they only get ourapp's powers: they can't read other people's files, change the program, or touch the rest of the system. That's the whole permissions lesson (Linux Basics, lesson 10) paying off.

sudo useradd --system --shell /sbin/nologin ourapp
getent passwd ourapp

ourapp:x:999:999::/home/ourapp:/sbin/nologin

sudo adduser --system --group ourapp
getent passwd ourapp

ourapp:x:107:111::/nonexistent:/usr/sbin/nologin

Releases and the current link

Here's a trick used everywhere from school servers to huge tech companies. Keep every version in its own folder, and point a link called current at the one you want:

# upgrade: unpack the new version next to the old one, switch the link, restart
sudo tar -xzf ourapp-1.5.0.tar.gz -C /opt/cht/ourapp/releases/
sudo ln -sfn /opt/cht/ourapp/releases/ourapp-1.5.0 /opt/cht/ourapp/current
sudo systemctl restart ourapp

# something broke? roll back in two seconds
sudo ln -sfn /opt/cht/ourapp/releases/ourapp-1.4.2 /opt/cht/ourapp/current
sudo systemctl restart ourapp

Settings and secrets

sudo cp /opt/cht/ourapp/current/share/ourapp.conf.example /etc/opt/cht/ourapp/ourapp.conf
sudo sed -i "s/CHANGE-ME/$(openssl rand -hex 32)/" /etc/opt/cht/ourapp/ourapp.conf
sudo chown root:ourapp /etc/opt/cht/ourapp/ourapp.conf
sudo chmod 640 /etc/opt/cht/ourapp/ourapp.conf     # root writes, ourapp reads, others: nothing

The $(openssl rand -hex 32) part makes a long random secret and drops it straight into the file, so you never have to see or copy it (lesson 2). Mode 640 with the ourapp group lets the app read its secret while ordinary users can't.

Before starting the service, test the app as its own user. Many real apps have a “check my settings” option like this one:

sudo -u ourapp /opt/cht/ourapp/current/bin/ourapp --check-config

sudo -u ourapp ourapp --check-config

Run it with systemd

The developers included a unit file. It's worth reading every line before you install it:

[Unit]
Description=ourapp - CHT ticket tracker
After=network-online.target

[Service]
User=ourapp                     # never root
Group=ourapp
ExecStart=/opt/cht/ourapp/current/bin/ourapp --config /etc/opt/cht/ourapp/ourapp.conf
WorkingDirectory=/var/opt/cht/ourapp
Restart=on-failure              # crash? systemd starts it again

[Install]
WantedBy=multi-user.target

sudo cp /opt/cht/ourapp/current/share/ourapp.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now ourapp
systemctl status ourapp
curl localhost:8080

The trap: SELinux labels on Rocky

Say you unpacked the app in your home folder first and then sudo mv'd it into /opt. That's a very common way to do it. On Ubuntu, it works. On Rocky, the service fails with status=203/EXEC … Permission denied, even though ls -l shows perfectly good permissions. What's going on?

ls -Z /opt/cht/ourapp/current/bin

unconfined_u:object_r:user_home_t:s0 ourapp

sudo ausearch -m avc -ts recent
sudo restorecon -Rv /opt/cht
sudo systemctl restart ourapp

ls -Z /opt/cht/ourapp/current/bin

? ourapp

Letting other computers in

ourapp listens on port 8080. curl localhost:8080 works on the server itself, but other machines also have to get through the firewall:

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

sudo ufw allow 8080/tcp

Try it: deploy ourapp 🚀

Priya from the dev team left two release files and a note in your home folder. Install version 1.4.2 properly, then upgrade to 1.5.0.

Quick check