| DistroWatch Weekly
|DistroWatch Weekly, Issue 816, 27 May 2019
Welcome to this year's 21st issue of DistroWatch Weekly!
Earlier this month we discussed the release of Red Hat Enterprise Linux 8.0. Red Hat is a long-running, profitable Linux company and manages to make money through support contracts while giving away the business's source code free of charge. This has allowed Red Hat to sponsor many open source developers and contribute heavily to the Linux ecosystem. This week we begin with a review of Red Hat Enterprise Linux 8.0, exploring some of its workstation and server features. In our News section we link to a discussion in the Void community about security and cover a media update from the Guix team which fixes a path issue that could prevent the Xfce desktop from starting. We also share a questions and answers session with Fedora's Matthew Miller and bid a fond farewell to the Antergos distribution. This week we also discuss firewall rules and ask, in our Opinion Poll, whether our readers feel the need to use a firewall at home. Plus we are pleased to share the torrents we are currently seeding and list the releases of the past week. We wish you all a terrific week and happy reading!
- Review: Red Hat Enterprise Linux 8.0
- News: Void discusses security, Guix publishes path fix, Antergos closes doors, Matthew Miller answers questions about Fedora
- Questions and answers: Setting up a firewall and finding service ports
- Released last week: openSUSE 15.1, Tails 3.14, Kali Linux 2019.2
- Torrent corner: ArchBang, BlackArch, Clonezilla, DragonFly BSD, Guix, Kali, Obarun, openSUSE, OSMC, Septor, SmartOS, Tails, Trident
- Upcoming releases: FreeBSD 11.3-BETA2
- Opinion poll: Do you enable a firewall on your computer?
- New distributions: Adelie Linux, EducatuX, TSURUGI Linux
- Reader comments
|Feature Story (by Jesse Smith)
Red Hat Enterprise Linux 8.0
Red Hat, the world's most profitable Linux company, released a new version of the company's flag ship product, Red Hat Enterprise Linux (RHEL), in the first week of May. The new release, RHEL 8, is based on Fedora 28 and introduces some interesting changes. RHEL 8 makes GNOME on Wayland the default desktop environment, provides the Cockpit remote management service pre-installed, and replaces the iptables firewall with nftables. Additional changes can be found in the distribution's extensive release notes, which I think are well worth a read.
Getting started with Red Hat's latest release took me through some difficult turns. RHEL is commercial software and requires the user to have a Red Hat account if we want to access the free 30-day evaluation ISO file. At first I went to the Red Hat website, went into the Downloads section, picked Enterprise Linux 8, and clicked the Try button. I was asked for my username and password at which point I discovered my old Red Hat account was no longer active (or I've lost the credentials). At any rate, I signed up for a new account, waited for the verification e-mail and, when it arrived, clicked the verification link. This took me to a page which read: "Unexpected error when handling authentication request to identify provider." I assumed several people were probably also signing up for new accounts on launch day, so waited a few minutes and went back to the first browser tab and requested a new verification e-mail. At which point I was told my account was already signed in and verified.
I went back to the download page, clicked the Try button and was offered a download called BinaryDVD. I clicked the link, downloaded the ISO and got to work. Booting from the media launched the Anaconda installer which has been lightly modified from Fedora's version of the installer to include some enterprise options and install-time customizations. I soon ran into a problem though as one of the installer steps demanded I provide a network URL for the source media and refused to proceed without a URL. The install steps on the website hadn't mentioned setting up source media and the built-in help documentation did not provide any clues.
I asked on-line about this and was told what I had downloaded was the Boot disc, not the full DVD. So I went back to the download page and noticed something interesting. The BinaryDVD download link showed it as connecting to the full DVD in my browser's status bar, but clicking the link redircted me to the net-install Boot disc ISO. I checked back a few days later and this had been fixed so clicking the BinaryDVD option would download the full DVD as expected. At the time I got around this issue by finding a second download page which listed all the different editions of RHEL for the various supported architectures and downloaded the full edition. There are quite a few editions from which to choose, including Red Hat Enterprise Linux, Workstation, Desktop, Atomic Host, Real Time, High Availability, and Container Development Kit. Selecting most of these indicates they are only available as older (7.x) versions. I went with the generic, default option which is an available flavour for version 8.0 and was a 6.6GB download.
Booting from the RHEL 8 media brings up a menu asking if we would like to launch the installer, boot from the hard drive, or run the media through a self-test. One aspect of RHEL I appreciate is the self-test is the default option and, assuming the media passes, the system then proceeds to launch the installer. This insures we start off from a position where we know the media has not been corrupted.
Once the Anaconda graphical installer launches we are asked to confirm our keyboard's layout. We are then given the chance to set our time zone and preferred language. There is a configuration screen which asks if we would like to provide links to media sources, with the installer defaulting to using the DVD. Another module asks us to pick the operating system's role. A role can be a Server (with graphical interface), a Server with just a command line interface, a Minimal Install, Workstation, Virtualization Host, or Custom. Each of these can further be customized with optional groups of packages. I decided to try the Workstation role, with some added packages.
Additional modules provide us with the means to enable and configure networking, create a root password, and optionally create a user account. The packages then copy to the hard drive which, in my case where I was installing the Workstation software and some extra items, took a little under an hour. The installer finishes its work and prompts us to reboot. An issue I ran into early on was, when the system reboots, the DVD stays in the drive. I found if I selected the option to boot from a local drive from the DVD's boot menu no suitable media would be found. Removing the DVD and booting directly from the hard disk did work.
The first time RHEL 8 boots, a graphical first-run wizard appears. The wizard asks us to accept Red Hat's license agreement and then asks for our Red Hat username and password so our installation can be activated. We then wait a minute while the system registers itself with Red Hat and confirms we have the proper license. The operating system then reboots. In my case, when it came back on-line, I was presented with a graphical login screen.
When I first started using RHEL 8 I noticed that, despite the release notes reporting GNOME and the GNOME Display Manager would use Wayland by default, both the GNOME Shell and GNOME Classic session that were available were run on X.Org sessions. I was not sure why at first, but I eventually discovered that RHEL will detect if the necessary video drivers are available for running Wayland and, if they are not available, the Wayland session options are hidden. This means people using some NVIDIA drivers and the default VirtualBox drivers will not be able to sign into a Wayland session. However, people running RHEL with Intel, AMD or VirtualBox add-on modules should see both the Wayland and X.Org session options on the login screen.
Red Hat Enterprise Linux 8.0 -- Running GNOME Shell
(full image size: 533kB, resolution: 1280x1024 pixels)
I played with all four session options (GNOME Shell and GNOME Classic, each running on X.Org and Wayland). To the distribution's credit, there was little difference to be found most of the time. GNOME Shell running on Wayland performed a bit faster than the same desktop on X.Org. GNOME Classic offered the same performance, regardless of the display server, but the Classic desktop locked up a couple of times when I was using the Wayland session and would no longer respond to mouse or keyboard input. The Classic desktop running on X.Org did not present me with any issues.
The first time I signed into the GNOME desktop a wizard appeared and asked me for my preferred language and asked me to confirm my keyboard layout. I was then asked if I would like to leave the desktop's location services turned on, or turn them off. We are then offered a chance to connect GNOME with on-line account services such as Google and Nextcloud. The wizard then disappears and the GNOME Help documentation appears in a new window. The Help window presents new users with a good deal of tips and tutorials on how to navigate the desktop and will probably be quite useful for people new to GNOME.
GNOME Shell is presented in a fairly minimal fashion, as is typical of GNOME these days. The Activities menu is placed in the upper-left corner and a dock sits on the left side of the screen, providing quick access to application launchers. The dock also offers a button for opening a full-screen grid of application icons. For the most part I tended to use the GNOME Classic desktop which is presented with a two-panel layout and tended to offer me better performance. One of my few issues with GNOME early on was the desktop kept locking every five minutes if I was not interacting with it. This setting can be changed in GNOME's Settings panel under the Power module.
Red Hat Enterprise Linux 8.0 -- Running the GNOME Classic desktop
(full image size: 502kB, resolution: 1280x1024 pixels)
When running RHEL 8 on my workstation, the distribution ran smoothly. All my hardware was detected and the installer was able to enable a network connection over both wired or wireless networks. Both versions of the GNOME desktop worked fairly well, whether running under a Wayland or X.Org session.
Working with the distribution in a VirtualBox environment presented more challenges. RHEL does not automatically integrate with VirtualBox and cannot use the host's full screen resolution and could not run Wayland sessions. The default repositories do not offer VirtualBox add-on modules and trying to install generic add-on modules failed until I had located and installed the elfutils-libelf-devel package using dnf. GNOME Shell was too slow to be used practically in VirtualBox, but the Classic shell worked well.
Disk and memory usage will vary a lot depending on which packages and services we enable at install time. In my case, running RHEL in a Workstation role, I found the distribution consumed 5.8GB of disk space. Running GNOME Shell used 980MB of RAM and GNOME Classic used 1,020MB of RAM. This is nearly double the RAM usage I see on most other distribution/desktop combinations and about about 20% higher than Ubuntu running the GNOME desktop on the same hardware.
One curious aspect of running RHEL 8 I found was boot times varied a lot. Sometimes the distribution started up and shutdown very quickly, starting faster than most other distributions I have tried recently, getting to the login screen in well under 20 seconds. Other times it could take nearly two minutes to start.
RHEL ships with a fairly standard set of open source applications. The Workstation edition offers Firefox, LibreOffice, Pidgin for instant messaging, the Evolution e-mail client and the HexChat IRC client. The Boxes virtual machine software is included along with a document viewer, the GNOME Files file manager and Java. The GNU Compiler Collection is installed too.
Red Hat Enterprise Linux 8.0 -- Running LibreOffice and viewing images
(full image size: 238kB, resolution: 1280x1024 pixels)
The distribution offers the Totem video player, the Cheese webcam utility, the Brasero disc burning software, and the Rhythmbox audio player. The available codecs are limited on RHEL. I was able to play audio files, including MP3 files, without any problem, but I was unable to play any local video files. Trying to open a video in Totem brings up a window letting us know the required codecs are missing and the system offers to search the repositories for the codec. This opens GNOME Software which reports it cannot find the necessary codec and invites us to read documentation about it. Clicking the documentation link opens Firefox to display a page from the Fedora website which discusses restricted codecs. That page, in turn, links to the Fedora Wiki, which then leads us to the RPMFusion website to get the missing codecs. RPMFusion does not have a repository compatible with RHEL 8, so the trail stops there.
In the past, I was able to get some third-party package support and restricted items through an extra Red Hat repository, but if it exists for RHEL it is not mentioned on any of the documentation pages we are shown, or mentioned in the software centre. When I searched for information on codecs on the Red Hat website all I found were documents for older versions which indicated media codecs could be downloaded from unnamed third-party repositories and were not supported.
Rounding out the collection of software, we find systemd is RHEL's init software and the distribution runs on version 4.18 of the Linux kernel.
One curious aspect to running programs on RHEL 8 was that, when I made a typo on the command line, the shell would pause for a few seconds (apparently trying to find a match for what I had typed in the repositories). The shell would then spew out the following error message:
Failed to search for file: cannot update repo 'rhel-atomic-7-cdk-3.5-source-rpms': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried; Last error: Status code: 404 for https://cdn.redhat.com/content/dist/rhel/atomic/7/7Server/x86_64/cdk/3.5/source/SRPMS/repodata/repomd.xml
I found this unpleasant for two reasons. The first is it slows down working at the shell every time a typo is made and, second, the error message makes it look as though the search function is looking in the wrong repository.
Red Hat Enterprise Linux 8.0 -- Trying to install Firefox extensions
(full image size: 130kB, resolution: 1280x1024 pixels)
When I first started using RHEL 8 I was unable to install any extensions in Firefox. This appeared to be a side effect of the Firefox certificate bug. However, after the Firefox update was installed a few days later I was still unable to install any extensions. Even with the certificate verification disabled I was still unable to install any extensions on Firefox, which may be the first time I have run into this problem on any distribution.
RHEL uses the GNOME Settings panel to customize and manage the desktop. The current Settings panel uses a two-pane layout with module names down the left side and specific settings on the right. The dual-pane layout makes it quicker to switch between modules and the whole Settings panel worked well for me. The options are generally well presented and easy to both understand and adjust.
Red Hat Enterprise Linux 8.0 -- Adjusting settings on GNOME Classic running on Wayland
(full image size: 274kB, resolution: 1280x1024 pixels)
Perhaps the only issue I ran into while using GNOME Settings was with the user account manager. The account manager would allow me to create new accounts, but when it came time to set a password, I had only two options: make a long, complex password that was not based on a dictionary word, or set no password at all and let the user make up one when they sign in. This everything-or-nothing approach continues when the user first signs in. A new user can login without a password, but they need to make up a long, complex one and, if their choice is not good enough, the user is logged out of the account, so they need to sign back in to try again. This seems like an unusually harsh way to introduce new users to the system. It is possible to adjust the password restrictions, but these feel like awkward defaults.
On a related topic, I noticed early on that RHEL is set up with the OpenSSH service running by default. The system allows remote logins using the root account. This too can be changed or disabled, but it is a potential security weakness that administrators should correct once they get the system set up with a non-root account. (Red Hat's upstream, Fedora, plans to disable remote, password-based logins in Fedora 31.)
When software updates are available a notification appears in the upper-right corner of the desktop. We can apply new software updates through either the GNOME Software graphical software centre, or through the dnf command line package manager. Installing updates through GNOME Software forces a restart if core packages are updated. Installing new versions of packages through dnf does not require us to restart the computer. On launch day there were 73 packages totalling 173MB in size available for download. More updates slowly tricked in over the next week I was using the distribution.
Red Hat Enterprise Linux 8.0 -- Trying to browse available software
(full image size: 141kB, resolution: 1280x1024 pixels)
I am sad to report GNOME Software did not work well for me at all. The software centre displayed no installed applications under its installed tab, and displayed no applications when I browsed through any of the available software categories. I also tried performing searches for common terms such as "firewall", "video", and "gimp" - each one returned no matches. At first I thought this strange behaviour might be a result of PackageKit not working properly (as it has caused problems on other distributions), but whether PackageKit was running or not, the software centre could not find any packages, installed or in the repositories.
This may be related to another problem I ran into. At first the dnf package manager could not find any packages either when I performed searches. I found dnf had to be run with sudo in order to return search results. For instance "dnf search firewall" would fail, but "sudo dnf search firewall" returned results. (I tried running GNOME Software with root/sudo privileges and it still failed to see any available or installed software.)
When run with sudo access, the dnf package manager typically worked well, successfully installing updates, downloading new programs and finding packages. Once, while installing the gimp package, dnf crashed before it was finished the installation and printed a Python traceback. Re-running the same install operation succeeded without further problems.
Red Hat Enterprise Linux 8.0 -- Searching for software
(full image size: 158kB, resolution: 1280x1024 pixels)
Incidentally, the Red Hat release notes refer to the package manager as being yum, the previous generation of package manager on RHEL, rather than dnf. However, on RHEL 8, both yum and dnf are symbolic links to the dnf-3 program and trying to open the yum manual page redirects us to the dnf page.
For people who like to use portable package formats, Flatpak is installed on RHEL by default. Users will probably want to enable third-party repositories in order to get the most out of Flatpak options. Snap support is not included by default and not available in the repositories.
Apart from the default firewall changing from iptables to nftables and RHEL adopting Wayland as the primary display technology, one of the features to catch my attention was Cockpit. The release notes describe Cockpit as follows:
Packages for the RHEL 8 web console, also known as Cockpit, are now part of Red Hat Enterprise Linux default repositories, and can therefore be immediately installed on a registered RHEL 8 system. In addition, on a non-minimal installation of RHEL 8, the web console is automatically installed and firewall ports required by the console are automatically open.
While Cockpit is indeed installed, it is not enabled by default. I started Cockpit using the systemctl command line service manager and found Cockpit listens for incoming web browser connections on network port 9090. We can sign into the web interface using our regular username and password.
Cockpit starts off by showing us a status board where we can get an overview of the system and its resource usage. Down the left side of the page we can see links that provide resources such as browsing logs, checking for software updates, managing background services, and manipulating user accounts. We can also make networking adjustments. There is a page for working with installed applications, but as with GNOME Software, no packages were visible on this page. There are a few other screens, one for checking for software updates, one for managing Red Hat subscriptions and one for running a terminal in the browser.
Red Hat Enterprise Linux 8.0 -- Viewing services with Cockpit
(full image size: 139kB, resolution: 1280x1024 pixels)
Apart from the software management page, the other resources generally worked well. I particularly liked the log browser which offers filters to help us find entries by time and type. I had not used Cockpit before, despite it being available on Fedora for a while, and was pleased with how quick the interface was and how easy it was to navigate. This was definitely a highlight of the trial for me.
However, there were two issues I ran into with Cockpit. I could start Cockpit whenever I wanted, but I could not enable the Cockpit service directly. Trying to enable Cockpit so it would be available at each boot resulted in an error from systemctl saying the service is not meant to be enabled. The Cockpit manual page says the web service is started on demand by systemd when we try to use it, which did not appear to be the case at first. I eventually found out that enabling the Cockpit service directly does not work, but enabling its socket does. Running "systemctl enable --now cockpit.socket" will cause the Cockpit interface to be available on demand at boot time. The other problem I ran into was with SELinux. At one point I wondered if SELinux might be causing some of the issues I was running into so went into Cockpit and toggled SELinux off. The web interface then told me to reboot to complete the action. When my system restarted SELinux was still enabled, indicating the Cockpit control had no effect.
My experiment with RHEL 8 got off to a rough start. Going through the on-line registration process produced some errors and ended up with me getting the wrong ISO which, in turn, resulted in some confusion and delays in getting the distribution installed.
Things then began to look up as RHEL 8 did a good job of detecting my system's hardware, registered itself without incident and offered good performance on physical hardware. I was particularly pleased that the distribution appears to detect whether our video card will work well with Wayland and either displays or hides Wayland sessions in response. I did have some trouble with the GNOME Classic Wayland session and GNOME Shell on X.Org was a bit sluggish. However, the Classic session on X.Org and GNOME Shell on Wayland both worked very well. In short, it's worthwhile to explore each of the four desktop options to see what works best for the individual.
The big issues I ran into with RHEL were with regards to software management. Both GNOME Software and the Cockpit screen for managing applications failed to work at all, whether run as root or a regular user. When using the command line dnf package manager, the utility failed to perform searches unless run with sudo and occasionally crashed. In a similar vein, the Bash feature that checks for matching packages when the user types a command name it doesn't recognize does not work and produces a lengthy error.
There were some security features or design choices that I think will mostly appeal to enterprise users, but are less favourable in home or small office environments. Allowing remote root logins by default on the Workstation role rubs me the wrong way, though I realize it is often useful when setting up servers. The enforced complex passwords are similarly better suited to offices than home users. One feature which I think most people will enjoy is SELinux which offers an extra layer of security, thought I wish the Cockpit feature to toggle SELinux had worked to make trouble-shooting easier.
I was not surprised that RHEL avoids shipping some media codecs. The company has always been cautious in this regard. I had hoped that trying to find and install the codecs would have provided links to purchase the add-ons or connect us with a Red Hat-supplied repository. Instead we are redirected through a chain of Fedora documentation until we come to a third-party website which currently does not offer the desired packages.
Ultimately, while RHEL does some things well, such as hardware support, desktop performance, and providing stable (if conservative) versions of applications, I found my trial highly frustrating. Many features simply do not work, or crash, or use a lot of resources, or need to be worked around to make RHEL function as a workstation distribution. Some people may correctly point out RHEL is mostly targeting servers rather than workstations, but there too there are a number of problems. Performance and stability are provided, but the issues I ran into with Cockpit, permission concerns, and command line package management are all hurdles for me when trying to run RHEL in a server role.
I find myself looking forward to the launch of CentOS 8 (which will probably arrive later this year), as CentOS 8 uses the same source code as RHEL, but is not tied to the same subscription model and package repositories. I am curious to see how much of a practical effect this has on the free, community version of the same software.
* * * * *
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, Ralink RT5390R PCIe Wireless card
- Display: AMD Radeon HD 6410D video card
* * * * *
Visitor supplied rating
Red Hat Enterprise Linux has a visitor supplied average rating of: 7.8/10 from 13 review(s).
Have you used Red Hat Enterprise Linux? You can leave your own review of the project on our ratings page.
|Miscellaneous News (by Jesse Smith)
Void discusses security, Guix publishes path fix, Antergos closes its doors, Matthew Miller answers questions about Fedora
There is always a balance to be found between security and convenience. For instance, complex passwords are more secure than simple ones, but less convenient to type. This week a discussion debating this balance has appeared in the Void project's issue tracker. The Void distribution, when installed from local live media, leaves a PolicyKit rule on the system which allows users in the wheel group to run commands as the root user without a password. Some see this passwordless access as a security concern while a few members of the development team see it as a convenience feature that makes working with the live system easier for users. Others have suggested that the default behaviour is not necessarily bad, but should be documented to better allow administrators to choose the right settings for their situation. The complete conversation can be found on Void's GitHub page.
* * * * *
The Guix project has published a bug fix release for Guix System just a few weeks after the distribution's 1.0.0 milestone was reached. The new version, 1.0.1, offers a number of fixes and improvements, but the main focus is on a bug which could prevent common command line utilities from being in the user's executable path, meaning the programs would not run if invoked without their full path name. The project's blog explains: "The 1.0.1 release was primarily motivated by bug #35541, which was reported shortly after the 1.0.0 release. If you installed Guix System with the graphical installer, chances are that, because of this bug, you ended up with a system where all the usual GNU/Linux commands - ls, grep, ps, etc. - were not in $PATH. That in turn would also prevent Xfce from starting, if you chose that desktop environment for your system. We quickly published a note in the system installation instructions explaining how to work around the issue."
* * * * *
Antergos, a rolling release distribution based on Arch Linux, is shutting down. The project has announced development of Antergos has ceased and website resources will be discontinued later this year. People currently using Antergos will be able to continue receiving package updates from Arch Linux repositories. "Today, we are announcing the end of this project. As many of you probably noticed over the past several months, we no longer have enough free time to properly maintain Antergos. We came to this decision because we believe that continuing to neglect the project would be a huge disservice to the community. Taking this action now, while the project’s code still works, provides an opportunity for interested developers to take what they find useful and start their own projects. For existing Antergos users: there is no need to worry about your installed systems as they will continue to receive updates directly from Arch. Soon, we will release an update that will remove the Antergos repos from your system along with any Antergos-specific packages that no longer serve a purpose due to the project ending."
* * * * *
Matthew Miller, Fedora's Project Leader, took to Reddit this past week to chat with the community and answer questions. Miller fielded questions on challenges Fedora faces, the project's release cycle length, Fedora's Silverblue edition, and reproducible builds, among other topics. The entire back and forth can be found in this Reddit thread.
* * * * *
These and other news stories can be found on our Headlines page.
|Questions and Answers (by Jesse Smith)
Setting up a firewall and finding service ports
Creating-firewall-rules asks: I've been setting up my firewall and started out by blocking everything, going out or coming in. Then added a rule allowing traffic out on port 80. When testing this, my web browser connects and shows me web pages. But doesn't this mean packets are coming into my computer too, even though I've only allowed outgoing traffic? Also, when I make new rules how should I go about finding out which ports need to be opened, for say NFS, and how do I know if it needs UDP or TCP?
DistroWatch answers: As far as troubleshooting your existing firewall rules are concerned, I see two possible explanations as to why your web traffic is getting through. The first, is that some firewall configuration tools will default to blocking all incoming traffic, or all outgoing traffic, but generally not both. You mentioned you began by blocking everything (which is a good start). But it could be that you are only blocking all traffic in one direction. If you are using a tool like gufw check to make sure both incoming and outgoing fields are set to Deny.
The second thing to consider is it sounds like you have successfully opened an outgoing port (80, in this case), but are not expecting traffic coming back from that connection to get through. Assuming I understand correctly, you are wondering why traffic comes back into your computer over port 80 when you have not yet created a rule allowing it. Firewall tools generally create rules based around initial connections rather than individual packets. So if you open a browser and try to form an outgoing connection over port 80, your firewall checks its rules and confirms this is allowed. When packets come back over this same connection, the firewall sees it has already allowed this connection and lets the packets into your computer. Likewise, if you allow traffic to come in on port 22 to allow secure shell access, you do not need to also explicitly allow outgoing traffic on port 22. The firewall rules cover how initial contact can be made rather than the back and forth packet traffic which results over the established connection.
As to how you can go about learning which ports to open in order to grant access to specific services, check out the text file /etc/services on your computer. It lists service names and their corresponding port numbers. NFS, for instance, is associated with port 2,049 and with both UDP and TCP. Its entry looks like this:
The entry for secure shell (ssh) is:
This tells us that secure shell needs network port 22 open and only uses TCP. If a network service is not listed in the /etc/services file, connection requirements will probably be mentioned in the service's on-line documentation. If that fails, a trick you can use is to start the service and then run the command
nmap -p 1-65000 localhost
This scans your own computer on its first 65,000 ports to see which ports are in use. (Almost all services use port numbers less than 65,000.) Even when the firewall is blocking all ports, nmap can see the service trying to use the port and will let you know which port number it is using and which protocol (TCP or UDP) it expects to receive.
* * * * *
Additional answers can be found in our Questions and Answers archive.
|Released Last Week
The Amnesic Incognito Live System (Tails) is a Debian-based live DVD/USB with the goal of providing complete Internet anonymity for the user. The product ships with several Internet applications, including web browser, IRC client, mail client and instant messenger, all pre-configured with security in mind and with all traffic anonymised. The distribution's latest release is Tails 3.14 which includes fixes for various CPU hardware bugs, updates the kernel and streamlines the live disc. "Upgrades and changes: Update Linux to 4.19.37 and most firmware packages. This should improve the support for newer hardware (graphics, Wi-Fi, etc.). Enable all available mitigations for the MDS (Microarchitectural Data Sampling) attacks and disable SMT (simultaneous multithreading) on all vulnerable processors to fix the RIDL, Fallout and ZombieLoad security vulnerabilities. Update Tor Browser to 8.5. Remove the following desktop applications: Gobby, Pitivi, Traverso." Further details and a list of known issues can be found in the project's release announcement.
Kali Linux 2019.2
Kali Linux is a Debian-based distribution with a collection of security and forensics tools. The distribution has published a new update, Kali Linux 2019.2, which includes updated tools and changes to the project's ARM builds: "Tool upgrades: This release largely features various tweaks and bug fixes but there are still many updated tools including seclists, msfpc, and exe2hex. For the complete list of updates, fixes, and additions, please refer to the Kali Bug Tracker Changelog. ARM updates: For our ARM users, be aware that the first boot will take a bit longer than usual, as it is requires the reinstallation of a few packages on the hardware. This manifests as the login manager crashing a few times until the packages finish reinstalling and is expected behaviour." Further details can be found in the project's release announcement.
Kali Linux 2019.2 -- Exploring the Lite edition's menu
(full image size: 884kB, resolution: 1280x1024 pixels)
The openSUSE team have announced the release of openSUSE 15.1. The new version introduces updated graphics support, Network Manager will handle network connections on desktop computers by default and YaST now offers more options for handling services, taking advantage of systemd features. "An entirely new graphics stack update is available for this stable community- and enterprise-based open-source GNU/Linux distribution. Graphics hardware supported by the 4.19 Linux Kernel were backported for the release of Leap 15.1, which uses the 4.12 Linux Kernel and supports additional graphics drivers for Graphics Processing Unit (GPU) and improved support for AMD Vega chipset. GPU virtualization has become quite popular among vendors like AMD, Intel and NVIDIA and Leap 15.1 helps to delivers these implementation and support solutions for virtualized and cloud environments. Leap 15.1 will now use Network Manager by default for both laptops and desktops - previously only laptops defaulted to Network Manager. Server installations will continue to default to Wicked, the openSUSE advanced network configuration system. The release adds a few popular WiFi drivers for more modern wireless chipsets. A change that applies to both Wicked and Network Manager is that /etc/resolv.conf, yp.conf and some other files are a link to a file in /run and are managed by netconfig. The management of system services in YaST has been revamped to take advantage of many of the features offered by systemd in that area." Further details can be found in the release announcement and in the release notes.
BlackArch Linux 2019.06.01
The developers of BlackArch Linux, an Arch Linux-based distribution designed for penetration testers and security researchers, and containing a large collection of penetration-testing and security utilities, have announced the release of version 2019.06.01. As usual, the new release updates the underlying Linux system and brings several new tools: "Today we have released the new BlackArch Linux ISO and OVA images. Here is the changelog: added more than 150 new tools; added 'jedi-vim' plugin; updated vim plugins; included Linux kernel 5.1.4; ISO image file cleanups and tweaks; updated blackarch-installer to vercion 1.1.1; updated Xresources and Xdefaults, plus added support for rxvt-unicode; package quality assurance (runtime checks) was performed prior the ISO image build; updated all BlackArch tools and packages, including configuration files; updated all system packages; updated all window manager menus (Awesome, Fluxbox, Openbox)." Visit the project's blog to read the full release announcement. The full BlackArch ISO image is now over 11 GB in size and only suitable for USB media or VirtualBox, but the project also provides a CD-size "netinst" image that pulls packages from the distribution's mirrors during installation.
* * * * *
Development, unannounced and minor bug-fix releases
The table below provides a list of torrents DistroWatch is currently seeding. If you do not have a bittorrent client capable of handling the linked files, we suggest installing either the Transmission or KTorrent bittorrent clients.
Archives of our previously seeded torrents may be found in our Torrent Archive. We also maintain a Torrents RSS feed for people who wish to have open source torrents delivered to them. To share your own open source torrents of Linux and BSD projects, please visit our Upload Torrents page.
Torrent Corner statistics:
- Total torrents seeded: 1,431
- Total data uploaded: 25.7TB
|Upcoming Releases and Announcements
Summary of expected upcoming releases
Do you enable a firewall on your computer?
For devices connected directly to the Internet, particularly ones which run network services, it is important to have a firewall in place to filter out unwanted traffic and prevent attacks against services. However, many personal computers run behind a router or other firewalled device and may not run any network services. This has led some people (and some distribution maintainers) to prefer to not use a firewall on their operating system.
We would like to know if you run a firewall on your personal desktop or laptop computer, or if you feel it is unnecessary.
You can see the results of our previous poll on running GNU/Linux distributions on mobile devices in last week's edition. All previous poll results can be found in our poll archives.
Using a firewall at home
|I do enable a firewall on my home computer: ||1179 (56%)|
| I do not enable a firewall on my home computer: ||679 (32%)|
| I use one on some home machine but not all: ||195 (9%)|
| Unsure: ||61 (3%)|
Distributions added to waiting list
- Adelie Linux. Adelie Linux is a distribution which strives to use free software exclusively. It uses the musl library and offers several desktop environments running on multiple hardware architectures.
- EducatuX. EducatuX is a Debian-based Brazilian distribution for use in classrooms. It features the Cinnamon desktop environment.
- TSURUGI Linux. TSURUGI Linux is an Ubuntu-based distribution used for forensics, malware analysis, and incident response investigation.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 3 June 2019. Past articles and reviews can be found through our Article Search page. To contact the authors please send e-mail to:
- Jesse Smith (feedback, questions and suggestions: distribution reviews/submissions, questions and answers, tips and tricks)
- Ladislav Bodnar (feedback, questions, donations, comments)
- Bruce Patterson (podcast)
|Linux Foundation Training
|Reader Comments • Jump to last comment
1 • RHEL 8 - sounds like a big fail (by Andy Prough on 2019-05-27 00:48:22 GMT from United States) |
The issue that really jumps out at me, aside from Gnome Software simply not working at all, is that RHEL did not even bother to document dnf correctly. Clearly, if RedHat is not even going to document its package manager accurately, they are not going after new users at all. They are only trying to work with users who are already used to all the various workarounds one has to use in order to get RHEL to do any work.
Kind of a sad state of affairs. You would think that after being bought by IBM there would be some effort by them to put out a high quality product this time.
2 • Documentation (by Jesse on 2019-05-27 01:02:34 GMT from Canada)
@1: I agree, that the big thing which kept jumping out at me was the lack of good documentation. With good documentation I wouldn't have been wondering why the first installer was demanding a repository URL (or would have known what the URL was), with proper documentation I wouldn't have wondered why Wayland sessions were not available when they were said to be the default in the release notes, documentation should have mentioned the Cockpit socket unit had to be enabled for the service to start on demand rather than having me hunt around for why Cockpit wasn't starting. Some of this documentation exists, but it wasn't always easy to find. I can put up with a lot of problems if they are clearly documented with errata or workarounds.
3 • RHEL 8 (by Pumpino on 2019-05-27 01:12:50 GMT from Netherlands)
I wonder if you can use the RHEL 7 or Fedora RPMs for RPM Fusion and EPEL.
There's no excuse for the software issues you experienced. I've been unable to upgrade from Fedora 29 to Fedora 30, as every time I do, Fedora isn't added to grub. There are various fixes posted, but none have worked. We shouldn't have to jump through hoops just to have basic functions work.
4 • Firewall (by Dawid on 2019-05-27 03:04:27 GMT from Germany)
I use standard setting of the distro
5 • BlackArch Linux2019.06.1 (by Bobbie Sellers on 2019-05-27 04:05:41 GMT from United States)
If you visit the site you will find in addition to the
mentioned iso files a 30 GB ova file.
Why does it need so much space?
I assume rejection of compression for some
6 • RHEL GNOME persistence dragging project down (by Simon Morgan on 2019-05-27 04:49:19 GMT from South Africa)
Why does Redhat continue to use a primary DE that is unsuitable for this type of purpose. In an enterprise environment users need a basic DE that at least offers conventional functionality without customisation and unofficial modding. Hearing about software centre issues is just the tip of the iceberg. This is becoming a joke.
7 • RedHat (by Alburgheiro on 2019-05-27 05:13:49 GMT from Russia)
RHEL is no longer the flagship product of RedHat (which now belongs to IBM) in the same way that Windows is no longer Microsoft's flagship product. I believe that the main source of revenue for both corporations comes from their cloud services.
8 • firewalls (by nanome on 2019-05-27 05:41:10 GMT from United Kingdom)
@4: In my experience, few distros install and enable any kind of firewall by default. I find this very disturbing: they could at least provide simple [g]ufw protection before the network is activated during install.
Having said that, I know people who rely on the firewall provided by their modem/router, even though these are often not documented.
9 • RHEL review, compared to openSUSE. (by gregzeng on 2019-05-27 07:38:38 GMT from United Kingdom)
Interesting to compare the open versus closed management systems. RHEL (reviews this week in DW) is the closed source copyright holder to the RPM package manager. So other RPM operating systems have great trouble with these packages. Fedora is excepted, because it is the open source version of closed source RHEL.
Similarly openSUSE is the open source version to SUSE. All four of these operating systems need to deal with RPM bugs with the dependencies.
The chairman of openSUSE is heavily "grilled" by four Linux journalists in the link:
"Destination Linux EP122" - Richard Brown of openSUSE, Published on May 23, 2019 by "Destination Linux". (85:07 minutes)
He admits to RPM operating systems having unreliable repositories:
46:30 The openSUSE repositories are lacking, because the RPM dependencies are so (bad, clumsy, ungainly?).
48:23 Flatpak, snap ... Are just re-inventing ... nightmares ... "; explaining why he like appimage (no dependency hell).
This might explain why the Debian package manager is preferred by most creators of Linux operating systems. The review in this week's Distrowatch seems to support this RHEL fault & bugs.
10 • Incorrect concepts (by Charlie on 2019-05-27 08:02:45 GMT from Hong Kong)
RHEL is NOT close source, neither SUSE.
Linux is licensed under GPL which ALL derivatives must be released under GPL as well. If RHEL is close source, how come there are RHEL clones like CentOS?
No free version available does not mean it's close source, ask Richard Stallman, the person who advocates free software the most, would give you the same answer.
Red Hat is NOT the copyright holder of RPM, same as Linux, RPM is an open source software released under GPL. It is originally developed by Red Hat but now it is contributed by the whole community. To reduce Red Hat's influence and color, RPM's full name is even changed from Redhat Package Manager to RPM Package Manager.
"The fault and bugs" appeared in the review, I believe, is a specific case in RHEL 8 because I'm happy with openSUSE and zypper, which use RPM and do not have such kind of issue.
Learn some facts before giving strong personal views.
11 • The review (by Charlie on 2019-05-27 08:12:46 GMT from Hong Kong)
I'm not sure the review can reflect the feature of RHEL.
Install codecs and Firefox extensions are concerns of desktop users and hobbyists, but I don't think users of RHEL care about that.
Most RHEL users are enterprises and developers, and they need RHEL for providing a stable base for development or running a easy-to-setup and easy-to-maintain server. I can't see such things in the review except going through the GNOME UI which the UX should be the same across all distros.
BTW RPM Fusion can provide codecs to RHEL just like Fedora and yes, it's well known only among Red Hat/Fedora users but I don't think it's hard to find out.
And one more thing, RHEL now provides free update to developers without support, as long as your system is not for production. Get a free copy of RHEL through developer program should be easier than the author to struggle with the try and download UI in Red Hat website.
12 • RHEL on the desktop (by Microlinux on 2019-05-27 09:16:17 GMT from France)
Even if I do use the RHEL clone CentOS on the desktop (with KDE and lots of third-party stuff), one should not forget that it is not targeted at desktop. I even suspect Red Hat to default to GNOME (an unusable desktop environment) to dissuade folks to use it in graphical mode.
13 • hbcdwin10 (by pavelbuidan on 2019-05-27 10:08:10 GMT from Romania)
off topic, this is my updated and customized Hiren's Boot CD Windows 10. yadi.sk/d/mnky3FnR_pl2Lg .maybe it's worth sharing here the download link...
14 • RHEL 8... (by MintyMan on 2019-05-27 11:02:09 GMT from Netherlands)
Although I haven't used RHEL since the earlier 2000's, I did run Fedora and Fedora-based distro's a couple of times. And compared with other distro's it was always a struggle to let it run smoothly. Not on one computer, but on multiple machines.
The curious thing here is that it wasn't only an "adventure" to run Fedora, I also tried distro's based on Fedora. I always had problems with it. It was always slow on updates, I regularly got a kernel panic, swap partition problems when installed in a dualboot setting. And on top of that it had troubles with translations in my own language (Dutch). I decided to never choose any Fedora/RHEL-based distro anymore because of the poor experiences with it. I replaced Fedora 29 Xfce (which was very slow) with Manjaro 18.0.4 Xfce, and guess what? It runs like a charm! Curious, isn't it?
My experience is that Debian- and Arch based distro's always run smoothly on all of my hardware, I rarely encounter problems or issues. Why do I have such different experiences with Fedora/RHEL-based distro's?
15 • using firewall (by MikeOh Shark on 2019-05-27 11:22:50 GMT from Austria)
I use iptables and ip6 tables behind my router. It's rare that I actually take my laptop with me to other locations but I keep my rules up to date so I'm ready when I need to go outside of the router rules.
Also, I have one port open on the router to enable me to run a personal https server when I want to exchange large files with family in remote locations. My rule drops all connections on the server port. When I start the server, I allow the connections until the need is complete. Then I reenable the rule and drop incoming packets again.
It's good to practice with firewall rules when the router rules have your back in case something is missed. Belt and suspenders.
16 • firewall (by dogma on 2019-05-27 14:03:47 GMT from United States)
I definitely use a firewall, as trusting a router manufacturer unnecessarily would be crazy.
17 • Antergos dies. (by mandatory on 2019-05-27 14:16:58 GMT from United States)
No more Antergos?
Well, that sucks.
What are we supposed to do for a plain, vanilla Arch install now?
(Inb4: Manjaro? * laughter * . . . )
Install "the Arch way"?
(Serious * laughter *. Get out.)
18 • Firewall and stuff (by Friar Tux on 2019-05-27 14:40:54 GMT from Canada)
Maybe it's my age, not sure, but my policy has always been, "Do not put on the Internet (or your computer) what you would not shout out in an auditorium full of gossips." I just checked and, nope, firewall is disabled. That's fine. I keep nothing on this laptop that is personal. I use my laptop for just about everything. It is my library (books), newspaper, magazine, technical journal, recipe box, encyclopedia, writer's tool (stories, poems, article, etc.), graphic artist's tool (painting, drawing, 'needle-work' - yup, you read that right), and much, much more. I usually spend about 8 -10 hours a day on it. This has helped to declutter/downsize the amount of stuff I would have had to cram into my, now, small apartment (780 sq. ft.).
Re:- RHEL/Fedora... unfortunately, this was my first sojourn into Linux. It had me run right back to Mama Windows. It wasn't until I discovered, and played with, Mandrake (3.1) that I realized Linux's potential. (I realized then that there were more than a few distros out there.) Since then I've played with hundreds of distros. RHEL/Fedora, and derivatives, still don't play nice, today, but with all the other distros out there, who cares.
19 • Arch (by RJA on 2019-05-27 15:33:19 GMT from United States)
"Install "the Arch way"?
(Serious * laughter *. Get out.)"
@17 I do agree at least somewhat! Because 9 years ago, when I tried Arch, my Arch mirror experience was extremely poor. :(
20 • @9 .deb vs .rpm popularity (developer wise) (by Titus_Groan on 2019-05-27 21:08:07 GMT from New Zealand)
regarding the popularity of .deb vs .rpm distributions.
A better reason would probably be that .rpm distros tend to be self contained.
This means the distro is maintaining their own mirrors and distribution completely.
This takes a lot of effort and resources.
As opposed to Debian offspring with perhaps the exception of Ubuntu.
to run linuxmint you need:
a very small linuxmint only repo and at least one mirror.
a very large Ubuntu set of repos and their mirror network.
a very small Linuxmint only repo and at least one mirror.
a very large Debian set of repos and their mirror network.
yet they market themselves as an independent distro, based on the small linuxmint repo..
you have a large set of PCLinuxOS repos and at least one mirror.
they market themselves as an independent distro.
If all of the Debian offspring had to maintain all their Distributions packages and cut apron strings to mum (Debian) or dad (Ubuntu) how many really would survive?
21 • Firewall? (by UZ64 on 2019-05-27 21:28:16 GMT from United States)
Only when using Windows, where the firewall is already basically set up by default and I don't trust the underlying operating system to begin with, I will leave it on. That OS tends to nag you for every single little "security" feature you turn off anyway, so why bother? Might as well just let it have its way so it leaves me alone; after all, it was programmed to believe that it knows best, I don't even bother fighting with it anymore these days.
This is even more true when using my laptop, if I ever connect it to a Wi-Fi network that is not under my control (especially unsecured, "public" hotspots)--but in this case, I would normally just play it safe anyway and connect using whatever Linux distro or other OS I have installed at the time. In this case, I see less of a need for a software firewall running on the local machine; other systems don't typically come with a firewall pre-configured, and I don't see a need personally to go out of my way to set one up. It's just more time wasted to have the system chew through more resources for no real benefit.
But that's under normal, "typical" circumstances I usually encounter these days; there is practically *always* a firewall protecting the local network and the machines connected to it from the outside Internet. In the case that this was not true, then yes--no matter what the OS, I would most definitely run a firewall at all times; even if the system is not set up as a server and does not have any unnecessary ports opened up, just as a safety precaution. The most I would give it is maybe 15-20 minutes unprotected (if Linux or BSD), but Windows I wouldn't even trust enough with a direct connection to the Internet even with its own firewall to give it that.
22 • Firewall - a Gothic Horror Story (by nanome on 2019-05-27 22:54:02 GMT from United Kingdom)
Twenty years ago, while playing with one of the early Redhat linux distros, I noticed strange activity from a mystery root user that wasn't me. I pulled the plug [dialup net and power], and found that I had interupted a hacker installing a Root Kit which was designed to be invisible [it replaced many of the commands that would reveal its existence]. In those days, a computer running Linux [or even better Unix] was likely a corporate treasure trove [mine was not]. Redhat had not installed a Firewall!
I quickly learned about simple iptables Firewall rules, and have since not been affected by malware. These days I use a more effective Firewall adapted from the contributions of Amaril Dojr. As I have total control of the init process [sinit+busybox scripts], I can ensure that the Firewall is enabled before connecting to the internet.
However, there is a problem. Most Linux distros are entirely unprotected [no Firewall] during installation. Only after a Firewall package such as ufw can be installed and enabled is there any degree of protection. Whilst the period in which a computer can be attacked may be only minutes, fast broadband permits much damage to be done. In the days when distros arrived on a shiny CD, there was time to install and enable a Firewall while the computer was offline.
I wonder how many distros are likewise unprotected during installation? Maybe router/modems offer this initial protective barrier.
23 • RHEL 8 review (by RJA on 2019-05-27 23:39:58 GMT from United States)
"One curious aspect of running RHEL 8 I found was boot times varied a lot. Sometimes the distribution started up and shutdown very quickly, starting faster than most other distributions I have tried recently, getting to the login screen in well under 20 seconds. Other times it could take nearly two minutes to start. "
Woah Jesse, that reminds me of Windows, (like post-XP) for RAM usage, if that's wired memory! Same with the random boot hangs. :(
24 • RPM (by César on 2019-05-27 23:40:52 GMT from Chile)
RPM vs DEB...DEB vs RPM. The great holy war begins again!!!
Why so many problem with RPM distros?
For example, CentOS, OpenSUSE, Mandriva and PCLinuxOS are excellent distros. Even in Slackware you can download, transform and install RPM packages if you want with "no problema". If you use the repos for you RPM distro (EPEL, RPM Fusion, Livna), no dependency hell.
Saludos desde Santiago de Chile.
25 • Antergos, Arch (by Archibald on 2019-05-28 00:52:27 GMT from United Kingdom)
@17 -Archman (Seriously.)
Can't say I'll miss Antergos. Trying to install it made "the Arch way" seem easy. That Cnchi thing was less of an installer and more of an implement of mental torture.
26 • Finest Arch Installers (by David on 2019-05-28 01:57:39 GMT from United States)
@17 - You may want to evaluate the most bulletproof Arch installer I have used to load up five boxes, four older Intel CPU's, including an eleven-year old Core 2 Duo E-8400, and one ten-year old AMD Phenom II quad-core - the Anarchy Linux installer. You'll get a 99.9% pure Arch installation, with no 3rd party repo's, as the principal maintainer removed his proprietary repo in the most recent very small ISO release. Very sweet, easy & stable Arch installer, which I don't understand why it's not more widely known and appreciated.
There's also the Zen Installer, but that ISO installs two extra repo's, none of which I want personally, but YMMV.
Archlabs is pretty good as well, and then there is the vastly underrated SwagArch XFCE ISO(in my opinion), but I haven't tested the newest Budgie-based ISO, which I have no personal interest in.
And then there's Artix, which just recently released a MATE-based ISO, if you want to try a systemd-free distro, I haven't tested that one yet, so I can provide no pertinent first-hand commentary on it.
Try them out - you may like one or all of them.
27 • Rpm vs deb distros (by Peter on 2019-05-28 06:49:01 GMT from Australia)
I have run openSUSE (as my main desktop OS) since 2007 and it was the first distro to offer delta rpms. That feature, amongst many others, make this rpm-based distro better-engineered than any deb-based one, IMO. RH also incorporated delta rpms in Fedora and RHEL a few years after.
Furthermore, the Yast2 Software Package Manager, IMHO, is also far superior to any graphical package manager found in Debian or Ubuntu derived distros. Last time I played around with Centos 7.x, there was hardly any graphical package manager worth mentioning.
Be that as it may, not everyone needs to use delta packages and installing normal full-size ones can be much faster (if one has a good internet connection). I did need delta packages as I have been using paid interned connections with limited data plans (lately mostly on mbb).
28 • graphical package manager (by Tim on 2019-05-28 09:00:56 GMT from United States)
I have to admit I'm at the point in life where I don't see any need for any graphical package manager. I guess they'd be helpful for someone new to Linux to find software they like, and maybe the rest of us should browse through one every five years or so to see if we've missed something.
But I just have a command saved in a text file that starts "sudo apt-get install... and then lists all the software I like. Install a new distro? Copy and paste that, let it run.
If I ever need the computer to do something it isn't currently doing I do a bit of research on what's out there, find the name of the new package, and install it. If it's worth keeping it gets added to the text file. That's about it.
29 • RPM packages (by Stevem on 2019-05-28 17:42:24 GMT from Switzerland)
Totally wrong claims, all of them. Please listen carefully to the chairman of OpenSuse before posting such crap.
30 • RHEL and the Linux desktop market (by Ankleface Wroughtlandmire on 2019-05-28 18:20:26 GMT from Ecuador)
What kind of enterprise workstation user could get their job done without at least occasionally viewing MP4 and other proprietary video files? Especially in an expensive commercial distro I would expect it to ship with legal proprietary codecs out of the box, or at the very least include an easy way to buy and install them from a third party. It's obvious that Redhat is not even trying with its desktop offerings anymore. Which is a shame, because that will cement the dominant position of Windows on corporate workstations, and the subsequent trickle-down effect on regular users' personal computers and the lack of commercial software for the Linux desktop.
31 • Bugs in RHEL 8 (by Dxvid on 2019-05-28 22:15:56 GMT from Sweden)
I'm astonished by RHEL having root on SSH on by default, and by the amount of bugs and problems in RHEL 8! It's supposed to be the "most stable Linux distro", but version 8 seems on par with small community distros. Obviously they would have needed to spend another couple of months doing testing and bugfixing before release.
The company I work at now has RHEL as the only allowed Linux distro, supposedly due to "security reasons" but I doubt the security is higher than the other major distros (SUSE, Debian, Ubuntu) if they ship RHEL 8 with root login in ssh on by default.
To RHEL's defence though the test is about workstation but most users will have RedHat run as a text only server and would only experience a few of the bugs/problems. They probably put all effort into making the command-line server mode stable and most likely put little effort in the other modes where they make less profit. Using this distro as a workstation or using video codecs is probably not very common, but still a buggy release like this can damage the brand name so they should be careful before releasing stuff that isn't sufficiently tested.
I wonder if the new owners have tried to stress them to make a new release before it was ready?
32 • finding service ports (by Dxvid on 2019-05-28 23:05:31 GMT from Sweden)
Another way of finding service ports if you use the most common Linux distros (SUSE, RedHat, Debian, Ubuntu):
This will show the services listening on various addresses and ports on your server/computer.
As a bonus, this one is also quite useful if you want to know how many people will get angry at you when rebooting a server:
It shows the amount of connections to the server, if there's a few thousand connected at the moment you might want to wait until it's night or early morning and fewer are using it. Normally a reboot can be done in 30s, but sometimes a lot of database stuff needs to be written on disk or a file system maintenance slows start-up down, or a bug in an update makes it impossible to reboot requiring fixing or rollback, or a cache takes minutes/hours to be populated with relevant data to speed up a server to normal speed. So in order to avoid making many people angry it can be good to either make a graph of server usage or use "ss -s" while logged in to see how many are connected.
(There's also special kernels made for high availability on busy servers in at least SUSE, Ubuntu and Oracle Linux requiring no reboot, but that's another chapter...)
33 • RPM distros & 'gut feelings' (by M.Z. on 2019-05-29 01:09:56 GMT from United States)
@10 & @ 29
Some people just like to spout the 'truthiness' that they feel in their gut, regardless of facts. It doesn't matter how much a commercially profitable distro gives back to upstream, some people will just hate them because [insert excuse here]. Of curse the truth is that commercially successful distros that act responsibly do a lot for the Linux community & making a fair profit was always supposed to be an option in free & open software.
I've had a few issues with Fedora myself over the years. I've only ever really tied to make it work seriously a couple of times or so & they all ended up with some significant snag after an upgrade. I think it may be related to the cutting edge nature that Fedora targets.
On the other hand, I've had excellent luck with Mageia for years & use is as an alternate/companion to Linux Mint on all my systems. As an added bonus, the two different Linux family dsitros offer a reasonably good chance of having hardware support the other may lack.
"...Yast2 Software Package Manager, IMHO, is also far superior..."
Ironic, the Yast thing was a big turn off for me. it felt so convoluted & poorly designed from a usability perspective. Not at all what I consider user friendly & package management on it made me want Synaptic. I think that the control centre in Mageia & PCLinuxOS hits a decent middle ground between Yast & less powerful options. Although those could also be a bit more clear & user friendly, I think they are almost perfect for a moderately technical user & quite powerful/useful as well.
34 • YaST (by Charlie on 2019-05-29 01:27:07 GMT from Hong Kong)
YaST is actually powerful instead of user friendly. That may be a problem for new Linux users, but once you know what it can do, you can unleash the full power of this tool.
35 • RHEL ssh root (by Andy Figueroa on 2019-05-29 01:46:54 GMT from United States)
"I'm astonished by RHEL having root on SSH on by default."
Which is upstream default on the open ssh server. :-(
36 • RHEL - What a POS! (by Paul M on 2019-05-29 04:03:00 GMT from Canada)
Shame on Red Hat for putting out such a piece of junk product! I can't believe that Jesse ran into all these problems with RHEL 8.0! It is near unbelievable that a product that costs a MINIMUM $299 for a year of support (RHEL Linux Workstation) does not even function at a bare minimum level.
IMHO, the devs at Red Hat should be lined up & smacked in the face, ala The Three Stooges, for putting out this pile of crap!
But, I suppose it's a good thing that Red Hat gets to wear egg all over their face... Maybe someday soon, their enterprise customers will do the smart thing: hire a team of Debian gurus to install/set up a fully functioning Debian network environment, then keep a couple of those guys on payroll full-time to keep the system up & running properly... and, voila... they would have a fully functioning, secure Linux OS! And these large enterprise clients could go this route for A LOT less money than buying RHEL support contracts!
37 • RHEL support (by Titus_Groan on 2019-05-29 05:11:52 GMT from New Zealand)
well, it a numbers game.
when the accountants determine that paying several full time employees will cost them less over a period (5 years) than the support costs, then yep, they will change in a heartbeat, or even faster.
you also need to take into account downtime to changeover to the "new system", downtime is lost money, never to be recovered.
then you have user inertia, " this isn't how we did it before", taking up those "couple of guys" time, full time, showing users how "we do it this way, now".
for a hint what it is like, try changing a Windows user who doesn't want to, over to Linux : wheres my internet? will be the first complaint.
this list goes on...
38 • Red Hat/Debian (by Vermilion Vermicelli on 2019-05-29 08:07:47 GMT from United Kingdom)
@36 -"Maybe someday soon, their enterprise customers will do the smart thing: hire a team of Debian gurus to install/set up a fully functioning Debian network environment, then keep a couple of those guys on payroll full-time to keep the system up & running properly.. . and, voila... they would have a fully functioning, secure Linux OS!"
Ahem!......Sorry! As I was going to type my reply, I could swear I saw a pig fly by my window.
39 • RHEL vs Windows, @50 (by Fred W. on 2019-05-29 08:36:39 GMT from United States)
"Redhat is not even trying with its desktop offerings anymore. Which is a shame, because that will cement the dominant position of Windows on corporate workstations,"
I don't know about that. The fall Windows 10 upgrade (1809) can be charitably called a sh*t sandwich. It was held back, and just the last two months is it being offered to all users. I just upgraded the newest one (1903) and had to dismember any system with more than one HD, remove any external drives, dongles and such, and copy the installer to "C" drive. Otherwise a no-go. Now my VMs don't work, among other things. The forums are alive with complaints. So what do enterprise users do? They do nothing. They wait to upgrade until after all the wailing and gnashing of teeth has died down, and most bugs have been squashed. I'm sure pretty much the same goes for Red Hat. RHEL 7 is still good for a few years.
40 • #39 Windows 1903 (by vern on 2019-05-29 15:51:49 GMT from United States)
"I just upgraded the newest one (1903) and had to dismember any system with more than one HD, remove any external drives, dongles and such, and copy the installer to "C" drive. Otherwise a no-go."
I noticed that myself. It took 30min of checking updates and in the end said USB and such can't be plugged in. Looking at the report it stated that MS is aware of the problem and is working a solution.
Regarding Red Hat. I can't recall ever installing that OS. Centos was good enough.
41 • Yast (by Friar Tux on 2019-05-29 17:30:45 GMT from Canada)
Re: the Yast package manager. I have stopped playing with/testing any distro using the Yast package manager. So far, every distro I've tried, Yast has CONSISTENTLY, without fail, quit or frozen while trying to install some software. And I mean consistently. Not sure why some of you think it's powerful. Synaptic Package Manager is powerful. Yast doesn't work.
42 • S**t happens (by whoCares on 2019-05-29 20:27:29 GMT from United Kingdom)
@39 & @40
Installed Win10 on 2 desktops and 4 laptops from USB without any issues. Desktops had 2 HDs and one of the laptops 3.
The issue is described on MS support site:
As you can see, it‘s actually a precaution feature if the system lose the track of devices.
Not good but s**t happens. It‘s still better than RHEL and SUSE issues.
One day RHEL didn’t start any more. Partition dissapeard from fstab.
SUSE updater brought the message: xy updates ready for install; contiuned install and never ever came further then the GRUB/choice of recovery points ... but it couldn‘t recover.
One has to inform himself before one starts, one has to know what one‘s doing and one has to be prepared that something sometimes can go wrong.
43 • RHEL in the wild (by Linux Enthusiast on 2019-05-29 21:20:22 GMT from United States)
IMO, this is a result of RHEL not being targeted for the "wild" and/or public consumption like most other distros. RHEL workstation works well in a corporate environment where enterprise admins can push policies to your workstation and make it do back flips upon request. But no one should be surprised with Jesse's review. RHEL workstations excel in a corporate, limited environment where control can be applied.
44 • @42, "Feature precaution" as a euphemism for "Oops, we screwed up!" (by Fred W. on 2019-05-29 21:54:36 GMT from United States)
Just because you have no issue does not mean there isn't one. I'm sure many have used RHEL without it disappearing from fstab, I'll take your word that yours did, as you say.
From your link: "To work around this issue, remove all external media, such as USB devices, SD cards and UFS cards, from your computer and restart installation of the Windows 10, version 1903 feature update. The update should then proceed normally. If you are using a installation media (USB flash drive, DVD, or ISO file) created by a tool to install Windows 10, copy the files on the installation media to your local drive, and then start the installation from the local drive"
This "precaution feature" was issued due to complaints, AKA feedback, from insiders. (I am one of those, on different rings.)
I had no issues with 1809 on my systems or those I installed for others, but that does not mean it was not pulled back after release due to the disappearing data bug and many other problems. Perhaps this "feature precaution" comes about because MS learned not to ignore the feedback form insiders as they did in 1809.
45 • Windows and Linux, yes, I still have hope for RedHat as well (by RJA on 2019-05-29 22:58:16 GMT from United States)
@39, Your issue with Windows, reminds me of XP. I found that Vista and later don't require me to disconnect my card reader.
The XP installer, requires me to disconnect the card reader and if I don't, the XP text mode installer will assign a higher letter in the alphabet to the primary master HDD and refuse to let me assign it to drive letter C!
Now on to Linux, despite the report I got about RedHat, I'm still see hope for the future.
Especially with the Windows Update issues...
46 • RPM, openSuse (by Kim on 2019-05-29 23:55:05 GMT from Austria)
No issues on openSuse with RPM whatsoever. But I never got the idea behind the necessity to have either DEB or RPM. Probably much too late to merge them ...
47 • @45 Re: XP and card readers (by Rev_Don on 2019-05-30 02:53:55 GMT from United States)
I never had any issues with XP and card readers. Never once in hundreds of installs did it not allow the primary master hard drive to be assigned drive letter C: with a card reader connected. In fact I've never heard of anyone having that issue.
48 • Red Hat, the world's most profitable Linux company...? (by OstroL on 2019-05-30 08:28:42 GMT from Poland)
"Red Hat, the world's most profitable Linux company, " starts the review...
Well, is it? It is now an IBM company, which might someday sell it or drop it.
Somewhere in 2004, IBM sold its PC business to Lenovo. Why? Because it was losing money!
The interesting part of that matter was that Lenovo hired the same management that IBM had at that time, and with Lenovo's ingenuity, it is one of the top PC companies in the world.But, IBM hiring the same management of Red Hat doesn't/won't do the trick -- don't have Lenovo's ingenuity. So, with IBM, this Red Hat would stop being the "most profitable company" and die away, or someone like Lenovo have to buy it. Would anyone buy it is the question...
49 • Happy Birthday Distrowatch! (by Bob on 2019-05-31 02:40:38 GMT from United States)
"Yes, it was exactly 18 years ago, on 31 May 2001, that DistroWatch was first published."
Full article here: https://distrowatch.com/dwres.php?resource=showheadline&story=8321
50 • red hat (by manticore on 2019-05-31 21:03:43 GMT from United States)
@48, Yes Red Hat is the most profitable linux company. They were the most profitable linux company before the IBM acquisition, and they have led all linux companies in this area for many years. They are the first two billion dollar company in the open source world, and they achieved that distinction as an independent company with their own linux distribution built from scratch. Nobody really knows what the acquisition will bring, but you can rest assured that Red Hat would be just fine if IBM sold or dropped them, similar to how the SUSE folks are still around despite what happened to them in the past.
51 • More 'Gut Feelings" etc. (by M.Z. on 2019-06-02 21:20:58 GMT from United States)
It seems perfectly obvious that a company with $3.4 billion in 2018 revenue & an estimated sale price of $34 billion is the worlds most profitable open source/Linux company, but then gut feelings get in the way. It's sort of a clash of world views & gut feelings vs reality. There are plenty of interesting & insightful questions about 'what now' after the IBM buy out, but too often we get silliness instead.
Q: Is it open source?
A: Of course, just check the license!
Q: Is it a big company?
A: Of course, just check the revenue number and the company sale price!
Better Q1: What are the odds of continued stable growth & profit from the new IBM open source division after the merger over the next 5-10 years? & how about after that?
Better Q2: What will change in the relationship between Red Hat & the open source community over the next 5-10 years? & how about after that?
A 1&2: ???
Yes, there are things you can do with is if you find it useful. I don't think I do, but then I suppose that's like the level of configuration options in KDE vs Gnome. I like both KDE & the happy middle ground of Cinnamon, while Gnome doesn't cut it. Similarly, the basic system level control options in most distros are a little lacking & Mageia MCC hits the sweet spot, while YaST seems to be by & for IT people & not particularly useful to me personally.
Number of Comments: 51
Display mode: DWW Only • Comments Only • Both DWW and Comments
|• Issue 843 (2019-12-02): Obarun 2019.11.02, Bluestar 5.3.6, using special characters on the command line, Fedora plans to disable empty passwords, FreeBSD's quarterly status report|
|• Issue 842 (2019-11-25): SolydXK 10, System Adminstration Ethics book review, Debian continues init diversity debate, Google upstreaming Android kernel patches|
|• Issue 841 (2019-11-18): Emmabuntus DE3-1.00, changing keys in a keyboard layout, Debian phasing out Python 2 and voting on init diversity, Slackware gets unofficial updated live media|
|• Issue 840 (2019-11-11): Fedora 31, monitoring user activity, Fedora working to improve Python performance, FreeBSD gets faster networking|
|• Issue 839 (2019-11-04): MX 19, manipulating PDFs, Ubuntu plans features for 20.04, Fedora 29 nears EOL, Netrunner drops Manjaro-based edition|
|• Issue 838 (2019-10-28): Xubuntu 19.10, how init and service managers work together, DragonFly BSD provides emergency mode for HAMMER, Xfce team plans 4.16|
|• Issue 837 (2019-10-21): CentOS 8.0-1905, Trident finds a new base, Debian plans firewall changes, 15 years of Fedora, how to merge directories|
|• Issue 836 (2019-10-14): Archman 2019.09, Haiku improves ARM support, Project Trident shifting base OS, Unix turns 50|
|• Issue 835 (2019-10-07): Isotop, Mazon OS and, KduxOS, examples of using the find command, Mint's System Reports becomes proactive, Solus updates its desktops|
|• Issue 834 (2019-09-30): FreedomBox "Buster", CentOS gains a rolling release, Librem 5 phones shipping, Redcore updates its package manager|
|• Issue 833 (2019-09-23): Redcore Linux 1908, why Linux distros are free, Ubuntu making list of 32-bit software to keep, Richard M Stallman steps down from FSF leadership|
|• Issue 832 (2019-09-16): BlackWeb 1.2, checking for Wayland session and applications, Fedora to use nftables in firewalld, OpenBSD disables DoH in Firefox|
|• Issue 831 (2019-09-09): Adélie Linux 1.0 beta, using ffmpeg, awk and renice, Mint and elementary improvements, PureOS and Manjaro updates|
|• Issue 930 (2019-09-02): deepin 15.11, working with AppArmor profiles, elementary OS gets new greeter, exFAT support coming to Linux kernel|
|• Issue 829 (2019-08-26): EndeavourOS 2019.07.15, Drauger OS 7.4.1, finding the licenses of kernel modules, NetBSD gets Wayland application, GhostBSD changes base repo|
|• Issue 828 (2019-08-19): AcademiX 2.2, concerns with non-free firmware, UBports working on Unity8, Fedora unveils new EPEL channel, FreeBSD phasing out GCC|
|• Issue 827 (2019-08-12): Q4OS, finding files on the disk, Ubuntu works on ZFS, Haiku improves performance, OSDisc shutting down|
|• Issue 826 (2019-08-05): Quick looks at Resilient, PrimeOS, and BlueLight, flagship distros for desktops,Manjaro introduces new package manager|
|• Issue 825 (2019-07-29): Endless OS 3.6, UBports 16.04, gNewSense maintainer stepping down, Fedora developrs discuss optimizations, Project Trident launches stable branch|
|• Issue 824 (2019-07-22): Hexagon OS 1.0, Mageia publishes updated media, Fedora unveils Fedora CoreOS, managing disk usage with quotas|
|• Issue 823 (2019-07-15): Debian 10, finding 32-bit packages on a 64-bit system, Will Cooke discusses Ubuntu's desktop, IBM finalizes purchase of Red Hat|
|• Issue 822 (2019-07-08): Mageia 7, running development branches of distros, Mint team considers Snap, UBports to address Google account access|
|• Issue 821 (2019-07-01): OpenMandriva 4.0, Ubuntu's plan for 32-bit packages, Fedora Workstation improvements, DragonFly BSD's smaller kernel memory|
|• Issue 820 (2019-06-24): Clear Linux and Guix System 1.0.1, running Android applications using Anbox, Zorin partners with Star Labs, Red Hat explains networking bug, Ubuntu considers no longer updating 32-bit packages|
|• Issue 819 (2019-06-17): OS108 and Venom, renaming multiple files, checking live USB integrity, working with Fedora's Modularity, Ubuntu replacing Chromium package with snap|
|• Issue 818 (2019-06-10): openSUSE 15.1, improving boot times, FreeBSD's status report, DragonFly BSD reduces install media size|
|• Issue 817 (2019-06-03): Manjaro 18.0.4, Ubuntu Security Podcast, new Linux laptops from Dell and System76, Entroware Apollo|
|• Issue 816 (2019-05-27): Red Hat Enterprise Linux 8.0, creating firewall rules, Antergos shuts down, Matthew Miller answers questions about Fedora|
|• Issue 815 (2019-05-20): Sabayon 19.03, Clear Linux's developer features, Red Hat explains MDS flaws, an overview of mobile distro options|
|• Issue 814 (2019-05-13): Fedora 30, distributions publish Firefox fixes, CentOS publishes roadmap to 8.0, Debian plans to use Wayland by default|
|• Issue 813 (2019-05-06): ROSA R11, MX seeks help with systemd-shim, FreeBSD tests unified package management, interview with Gael Duval|
|• Issue 812 (2019-04-29): Ubuntu MATE 19.04, setting up a SOCKS web proxy, Scientific Linux discontinued, Red Hat takes over Java LTS support|
|• Issue 811 (2019-04-22): Alpine 3.9.2, rsync examples, Ubuntu working on ZFS support, Debian elects new Project Leader, Obarun releases S6 tools|
|• Issue 810 (2019-04-15): SolydXK 201902, Bedrock Linux 0.7.2, Fedora phasing out Python 2, NetBSD gets virtual machine monitor|
|• Issue 809 (2019-04-08): PCLinuxOS 2019.02, installing Falkon and problems with portable packages, Mint offers daily build previews, Ubuntu speeds up Snap packages|
|• Issue 808 (2019-04-01): Solus 4.0, security benefits and drawbacks to using a live distro, Gentoo gets GNOME ports working without systemd, Redox OS update|
|• Issue 807 (2019-03-25): Pardus 17.5, finding out which user changed a file, new Budgie features, a tool for browsing FreeBSD's sysctl values|
|• Issue 806 (2019-03-18): Kubuntu vs KDE neon, Nitrux's znx, notes on Debian's election, SUSE becomes an independent entity|
|• Issue 805 (2019-03-11): EasyOS 1.0, managing background services, Devuan team debates machine ID file, Ubuntu Studio works to remain an Ubuntu Community Edition|
|• Issue 804 (2019-03-04): Condres OS 19.02, securely erasing hard drives, new UBports devices coming in 2019, Devuan to host first conference|
|• Issue 803 (2019-02-25): Septor 2019, preventing windows from stealing focus, NetBSD and Nitrux experiment with virtual machines, pfSense upgrading to FreeBSD 12 base|
|• Issue 802 (2019-02-18): Slontoo 18.07.1, NetBSD tests newer compiler, Fedora packaging Deepin desktop, changes in Ubuntu Studio|
|• Issue 801 (2019-02-11): Project Trident 18.12, the meaning of status symbols in top, FreeBSD Foundation lists ongoing projects, Plasma Mobile team answers questions|
|• Issue 800 (2019-02-04): FreeNAS 11.2, using Ubuntu Studio software as an add-on, Nitrux developing znx, matching operating systems to file systems|
|• Issue 799 (2019-01-28): KaOS 2018.12, Linux Basics For Hackers, Debian 10 enters freeze, Ubuntu publishes new version for IoT devices|
|• Issue 798 (2019-01-21): Sculpt OS 18.09, picking a location for swap space, Solus team plans ahead, Fedora trying to get a better user count|
|• Issue 797 (2019-01-14): Reborn OS 2018.11.28, TinyPaw-Linux 1.3, dealing with processes which make the desktop unresponsive, Debian testing Secure Boot support|
|• Issue 796 (2019-01-07): FreeBSD 12.0, Peppermint releases ISO update, picking the best distro of 2018, roundtable interview with Debian, Fedora and elementary developers|
|• Issue 795 (2018-12-24): Running a Pinebook, interview with Bedrock founder, Alpine being ported to RISC-V, Librem 5 dev-kits shipped|
|• Issue 794 (2018-12-17): Void 20181111, avoiding software bloat, improvements to HAMMER2, getting application overview in GNOME Shell|
|• Issue 793 (2018-12-10): openSUSE Tumbleweed, finding non-free packages, Debian migrates to usrmerge, Hyperbola gets FSF approval|
|• Issue 792 (2018-1203): GhostBSD 18.10, when to use swap space, DragonFly BSD's wireless support, Fedora planning to pause development schedule|
|• Issue 791 (2018-11-26): Haiku R1 Beta1, default passwords on live media, Slax and Kodachi update their media, dual booting DragonFly BSD on EFI|
|• Full list of all issues|
Star Labs - Laptops built for Linux.
View our range including the Star Lite, Star LabTop and more. Available with a choice of Ubuntu, Linux Mint or Zorin OS pre-installed with many more distributions supported. Visit Star Labs for information, to buy and get support.
|Random Distribution |
ToOpPy Linux is a French distribution based on Puppy Linux. The project provides a lightweight distribution which includes many small utilities and can be run either from a live disc or installed on the hard drive.