A few articles ago I had talked about the pros and cons of Ubuntu on Power solutions, promising in some comments to do an article outlining the installation steps, and here it is.
Requirements
To proceed with the installation, it is essential to have created the partition. In my example, the partition was created with 0.1 core, 16 GB RAM and 50 GB on IBM storage presented to the partition via SAN. These are clearly my figures, you can change them if you want to give more resources or if you use different technology for storage access such as storage pools.
This is the detail on the disk created on the storage:
Now, once the infrastructure setup is done, so the partition sees the storage and the disk presented to it, we can proceed with downloading the Ubuntu image directly from the official site and upload it to the VIOS (see this documentation if you don’t know how). The last step before being able to turn on the machine involves the creation of a virtual optical, so again from HMC in the ‘Virtual Storage’ panel we go to select the tab for virtual optical and click on the add button selecting the VIOS on which the file with the operating system image has been uploaded.
Installation
Connect to HMC using SSH, choose the correct server in which partition is with VTMENU command and after that choose your partition:
Start partition in SMS mode (SMS mode is a function like the computer’s BIOS)
Now follow the steps proposed in these screens
If everything works fine, and you choose every time the correct option, grub will star in a few seconds
Ok, now the installation will proceed like in any other architecture, you need to choose which network card do you want to use, disk and file systems configuration and the first user for this server. Once the installation is completed you can restart the partition:
POST INSTALLATION CHECK
One of the most important things in my opinion is the multipath support that is natively installed, to check that run multipath -ll and it will show you all path for your disk. In my scenario, I willl have 4 active paths to my disk for each VIOS:
As another proof that everything works fine, as you can see Ubuntu gave me the same disk serial as the storage.
Take note that this short tutorial was written for Ubuntu, but also works fine with other distros such as Debian or any other distros that support PPC64LE architecture.
On IBM i systems, the SSH service is playing an important role in modernisation, it can be used, for instance, to take advantage of new software development tools such as VS Code For I, or it can be used in an innovative software release context using pipelines. SSH (or rather SFTP) is also playing a key role in securing data exchange flows by gradually replacing the plain-text transfers that used to use the FTP protocol, popular in the IBM i context.
At the moment SSHD server doesn’t have any kind of exit point that we can use in order to restrict or manage connections to this server… This doesn’t mean that is not possibile to make this server secure! In this article we will show how to restrict access to specific users (or groups of users) and log the access attempts that are made.
What do we need to know? Well, the SSHD server has the same behavior that it has on other platforms and therefore allows you to use the same directives, so if you are familiar with some other UNIX like platform, well in this case you won’t have any kind of problem. As far as logging is concerned, again we will use a very convenient and widely used utility on UNIX systems namely syslogd.
How to configure and activate SysLogD?
This service is automatically installed with the 5733SC1 operating system product. Activating the daemon is quite simple, you only need to submit a job that activates it as per this command: SBMJOB CMD(STRQSH CMD(‘/QOpenSys/usr/sbin/syslogd’)) JOB(SYSLOGD) JOBQ(QSYSNOMAX) (P.S. you need to put this command into you QSTRUP)
To check that’s everything ok, you need to look in your NETSTAT opt. 3 and in this way you need to find the UDP port 514 in listening status.
So, now that the deamon is active, you need only to change your SSHD configuration file in order to send to syslog server all entries:
Restart sshd server and check into /var/log/messages or /var/log/auth files
How to restrict access to ssh?
The logic behind the configuration of user restriction in ssh can be bi-directional, i.e. defining a list of users who are not authorised to connect and consequently all the others are, or defining the list of users who are authorised and the others are not. In my case, the choice falls on the second possibility by authorising access to this service to restricted groups of users.
