DistroWatch Weekly, Issue 705, 27 March 2017

Feature Story (by Jesse Smith)

Minimal Linux Live



Minimal Linux Live is, as the name suggests, a very minimal Linux distribution which can be run live from a CD, DVD or USB thumb drive. One of the things which set Minimal Linux Live (MLL) apart from other distributions is that, while the distribution is available through a 7MB ISO file download, the project is designed to be built from source code using a shell script. The idea is that we can download scripts that will build MLL on an existing Linux distribution. Assuming we have the proper compiler tools on our current distribution, simply running a single shell script and waiting a while will produce a bootable ISO featuring the MLL operating system.



Yet another option the MLL project gives us is running the distribution inside a web browser using a JavaScript virtual machine. The browser-based virtual machine running MLL can be found on the project's website, under the Emulator tab. This gives us a chance to try out the operating system in our web browser without installing or building anything.



I decided to try the MLL build process to see if it would work and how long it would take if everything went smoothly. I also wanted to find out just how much functionality such a small distribution could offer. The project's documentation mostly covers building MLL on Ubuntu and Linux Mint and so I decided to build MLL on a copy of Ubuntu 16.04 I had running in a virtual machine. The steps to build MLL are fairly straight forward. On Ubuntu, we first install six packages to make sure we have all the required dependencies. Then we download an archive containing MLL's build scripts. Then we unpack the archive and run the build script. We just need to type four commands in Ubuntu's virtual terminal to kick-start the build process. Those commands are: sudo apt-get install wget make gawk gcc bc genisoimage

wget http://minimal.linux-bg.org/download/minimal_linux_live_20-Jan-2017_src.tar.xz

tar xJf minimal_linux_live_20-Jan-2017_src.tar.xz

sh build_minimal_linux_live.sh The MLL script downloads the source files we will need, unpacks everything and compiles the necessary software. Then the script builds an ISO file for us. The script completed without any errors on my first try, which is always nice to see. The project's documentation suggests MLL can be built in less than 30 minutes on a modern computer and I think that is accurate. I performed the build in a virtual machine with access to just one processor and 2GB of RAM and, in this limited environment, MLL took one hour and 14 minutes to build its ISO from scratch. The build required about 1.8GB of disk space to download all the source code, compile everything and build the ISO file.



I tried running MLL in two test environments, a physical desktop computer and a VirtualBox virtual machine. The distribution worked in both environments, booting quickly to a text console where I was automatically signed in as the root user. There are no desktop environments or multimedia applications, making sound and video support somewhat unimportant. In both environments, MLL detected my network connection and set up networking using DHCP. Memory usage varied a fair amount from one session to the next. I found MLL generally used approximately 10MB to 40MB of RAM when no extra programs or services were running.



A curious person might be wondering just how much we can do with a Linux distribution that has an ISO file smaller than 7MB. MLL offers a very bare bones environment. The distribution boots to a text console where we can run a shell as the root user. We have access to the Busybox command line utilities (lightweight versions of the GNU and Unix command line programs) and the system has a copy of the GNU C library. The operating system activates a network connection and uses DHCP to try to obtain an IP address for us. That is about all we have. There is a manual page utility, but no manual pages are available by default. We can partition a local disk drive, use dd to copy partitions and use wget to download files - that is about the extent of our tools and access. In the background MLL runs version 4.4 of the Linux kernel.



I found that with the default build settings, MLL did not provide a secure shell client or FTP client for transferring files, nor any web browser. However, MLL does provide an option to enable extra features at build time. When we download the MLL build scripts there is a file called .config where we can set options. Commenting or un-commenting options in the .config file allows us to include additional services in MLL, such as the Links text-based web browser, Java and the Dropbear secure shell software.



Conclusions



I was intrigued by Minimal Linux Live, particularly by the idea of using just one shell script command to build the entire operating system. I was pleased to find the distribution does indeed build and run exactly as the documentation says it will. I was also interested in running such a minimal environment in a web browser and was pleased to find MLL does run (admittedly slowly) in a browser. There is not a lot we can do with a command line only distribution in a web browser, but I can see how it would be a useful educational tool.



In a way I feel as though MLL is Linux From Scratch for people who want to automate the build process, skipping the manual work. And, in this regard, MLL is effective. We can run the build script and come back an hour later to a working, tiny distribution.



There is not a lot we can do with MLL on its own, apart from testing hardware, rescuing files or running simple scripts. However, the platform is there to build upon. Much like other minimal distributions, such as Tiny Core Linux, the power of MLL is not in what it does, but in providing a core platform on which we can expand. In this regard, MLL does very well. * * * * * Hardware used in this review



My physical test equipment for this review was a desktop HP Pavilon p6 Series with the following specifications: Processor: Dual-core 2.8GHz AMD A4-3420 APU

Storage: 500GB Hitachi hard drive

Memory: 6GB of RAM

Networking: Realtek RTL8111 wired network card

Display: AMD Radeon HD 6410D video card

Miscellaneous News (by Jesse Smith)

New KaOS features, Uplos32 forked from PCLinuxOS, openSUSE 42.1 approaches its end of life



The developers of KaOS, a rolling release distribution with a focus on KDE and Qt technologies, have introduced a number of new features and improvements. The project's March status update talks about the new ability to find reverse dependencies in the on-line package viewer, several updates to key software components and adding VirtualBox integration to the live media. The report also mentions future snapshots will feature a version of the Calamares installer which will be able to work with GPT disk layouts. " Quite a lot of changes to report here for the last five weeks. A new major systemd release (233) required changes in how the live environment needs to run, it took a half dozen internal test ISOs to have all that working correctly again. Mesa has moved to the 17 series (currently at 17.0.2), this looked for a little while that it would break the use of QtWebengine on Nouveau systems again, but luckily the three needed Nouveau patches could be adjusted to have no such issues. New poppler, libbluray and libarchive required the usual sizable rebuilds. A major CVE caused a quicker than normal update of the stable kernel, Linux 4.9.12 was moved to all users shortly after receiving the 4.9.10 update. " * * * * * PCLinuxOS is a rolling release distribution which, like many other projects, has been gradually transitioning to newer technologies. PCLinuxOS has migrated from the KDE 4 desktop to KDE's Plasma 5 desktop environment. The project has also shifted away from supporting 32-bit computers, focusing on building 64-bit packages and installation media. Some users of the distribution have decided to fork PCLinuxOS in order to continue support for 32-bit computers. The Uplos32 project was created with the intention of continuing support for users of PCLinuxOS who still run legacy 32-bit systems. * * * * * Marcus Meissner of the openSUSE Maintenance Team has sent out a reminder that openSUSE 42.1 will reach the end of its supported life in May of 2017. " With the release of openSUSE Leap 42.2 the SUSE support of openSUSE Leap 42.1 will be ending in two months, around May 16th 2017. Please check https://en.opensuse.org/Lifetime for lifetime information. Note that the openSUSE Leap 42 class of distributions is designed to be easily upgradable within minor versions, so Leap 42.1 to Leap 42.2 update should be easy and seamless. * * * * * These and other news stories can be found on our Headlines page.





Questions and Answers (by Jesse Smith)

Sharing control of the operating system



Sharing-the-power asks: Too many simple tasks on Linux require the admin password. Changing settings, installing games, setting up a printer all requires my root password. Is there any way I can share control over parts of the system with my family without giving my kids access to everything?



DistroWatch answers: The traditional Linux approach to permissions, granting one person (the root user) unlimited access and power while everyone else has very restricted access, is a bit limiting. It made sense back when an entire company or university might share one computer and there was just one system administrator. These days though, when families share desktop computers and companies might have dozens of system administrators, it makes sense to have a way of sharing responsibility. Luckily, there are tools to accomplish this, specifically sudo on Linux and either sudo or doas if you are running one of the BSDs.



Both sudo and doas work approximately the same way and I'll focus on sudo for the moment. The system administrator creates a few rules, basically telling sudo who gets to do what. For example, Alice might get to use the package manager while Bob gets to configure printers. Then, whenever Alice wants to install updates she can use the sudo command (or one of its graphical equivalents like gksudo or kdesudo) to launch the package manager. Alice will be prompted for her password to confirm it is really her and then sudo checks to make sure she is allowed to access the resource. Assuming Alice provides the right password and is running a command sudo has been told she is allowed to run, the command works as though she were the system administrator.



The sudo program can be configured to log commands people run or report to the administrator when an unauthorized user attempts to use sudo to elevate their access. In this way sudo can be used to log what users on the system are up to as well as police admin access.



One of the few drawbacks to using the sudo command is that its configuration file, where we specify rules stating who may do what, can get a bit complicated. The manual page explaining all the options for the sudo configuration file is over 2,000 lines long. (The sudo configuration file is called sudoers and can usually be found at the location /etc/sudoers.) Luckily, there are several good examples of how to set up rules (even relatively simple ones) at the bottom of the sudoers manual page.



The sudoers configuration file is usually edited and updated using a tool called visudo. This tool performs some safety checks on the sudoers file to help us avoid breaking users' access to the system.



As mentioned above, there are a lot of options when dealing with sudo and its configuration file, sudoers, but I will cover a couple of very simple examples. Each entry in the sudoers file generally contains four parts: the person who may run a command, the computer they are running on, who they can be running as and the command you have given to them. Usually the computer name doesn't matter and can simply be listed as "ALL". In the following example, we give Alice access to the DNF package manager. First, we open the sudoers file with visudo The visudo command opens the sudo configuration file for us. We can scroll down to the bottom of the file and add an entry for Alice: alice ALL=(ALL) /usr/bin/dnf In the above example, we grant a user (Alice), permission to run a command from any computer (ALL), as any user (the second ALL) and the command she can run is the package manager located at /usr/bin/dnf. Were we to grant Bob access to configure printers on the system we could use the visudo editor to add a new entry: bob ALL=(ALL) /usr/bin/system-config-printer We can go a step further and allow a user to shut-down the operating system without specifying a password by using the NOPASSWD keyword: calvin ALL=(ALL) NOPASSWD: /sbin/shutdown One reason some people, particularly BSD users, tend to use the doas command instead of sudo is the doas command has a simplified syntax. The doas command has shorter manual pages and does not recommend using a special editor to update the configuration file. When doas is installed, we can simply open the doas.conf configuration file (usually saved as /usr/local/etc/doas.conf) in a text editor and create entries using an almost English-like syntax.



Below is the line we would put in the doas.conf configuration file to grant Alice permission to the DNF package manager. Each line granting access begins with the word "permit" followed by the user's name, who they may run the command as and the name of the command we are granting them permission to run. permit alice as root cmd /usr/bin/dnf And here is the line to grant Bob permission to manage printers using doas: permit bob as root cmd /usr/bin/system-config-printer Finally, here is the doas.conf line for granting Calvin permission to shut-down the computer without a password using the "nopass" keyword: permit nopass calvin as root cmd /sbin/shutdown Further information on how to use these two commands, sudo and doas to grant program access to specific users can be found in the sudoers and doas.conf manual pages respectively. * * * * * We have more answers in our Questions and Answers archive.





Released Last Week

Torrent Corner

Upcoming Releases and Announcements

Opinion Poll

Gaining elevated access for administrator tasks



In this week's Questions and Answers column we discussed ways to elevate a regular user's access so they can perform system administration tasks. In this poll we would like to find out what method you use to gain administrator-level access to your operating system. Do you log into your root account directly, use su to switch between user accounts, or use a tool like sudo or doas to grant temporary root access?



You can see the results of our previous poll on changing the look of the website's header in last week's edition. All previous poll results can be found in our poll archives.



Gaining elevated access for administrator tasks

I log into the root account I use the su command I use sudo I use doas I do not have root-level access