Wednesday 13 November 2013

The gksu problem

We had a real problem with ktsuss/gksu while developing for 14.1. It seems that newer versions of the shadow package, and certainly the one that is included in Slackware 14.1, don't allow su to be executed in any other way except directly from a terminal. That means that su cannot be executed as a subprocess from inside ktsuss or the original gksu anymore and these become effectively useless. This is a critical issue for us, because if we don't fix it, almost nothing in the System part of the menu would actually work.

gksu-polkit works around this problem by using policykit for getting superuser proviliges, but it doesn't seem to be developed and it has terrible bugs that cause the CPU to hit 100% and stay there. It would fry your PC.

So, one solution, was to patch ktsuss to actually open a terminal and execute su from inside a terminal. But that would mean a terminal popping on the screen and staying there for the duration that you had the application that you launched open. And if you actually closed the terminal, the app would close too. Ugly.

The other solution would be to stick with the shadow version that came with 14.0. ktsuss works fine with that. But we can't rely on older versions of software like that. We can't keep the old version forever and this was no real solution.

So, in the absense of anything else out there that fixes this problem, there was nothing else left but writing my own. Enter gnsu (Gnsu's Not SU). It's actually a couple of rather simple shell scripts that use yad to display a window requesting the user password to get superuser rights using sudo as a backend.

That means that you don't have to provide (or know) the root user password to launch an app with superuser priviliges. But you need to be included in the sudoers list. So you would have to run visudo from a root terminal and add something like the following somewhere in the file:
george ALL=(ALL) ALL
to allow user george to run apps with superuser priviliges, or something like:
%users ALL=(ALL) ALL
to allow anyone in the users group to do the same.

I chose yad for displaying the password request window, for the reason that it has more features than other similar apps out there and would allow me to make the window a bit more beatiful, by displaying an icon in it. It would be trivial to patch gnsu to use zenity, matedialogs, xdialog or any other similar app out there.

The code for gnsu is up on github. It's in early stages, but it works. I still want to add some things, like support for translations and a Makefile, but these can come later. Oh, I could use the strings from our ktssuss translation project, so it would be already translated.

Now, just symlink gnsu to gksu (not necessary if you install the gnsu package) and everything should work.

There is an added benefit by using sudo as the backend; if you launch something with gnsu from a terminal and then launch something else with gnsu again from the same terminal in a short time after the first one, you don't get a password request the second time (or third, or forth...). This behaviour can be tweaked by editing sudo settings.

Can't get any more simple than that.

Plus, I always wanted to name something with a recursive acronym. :D

Wednesday 30 October 2013

How much of Slackware is in Salix?

That is a question that I had in my mind for a while. At some point I had also done the actual counting, so I had an idea, but I never wrote anything down.

There are many people that believe that a derivative distribution only just leeches their parent distribution, maybe changing the default wallpaper or a couple of settings here and there and making a release. I know for a fact that some people that have never tried Salix (or have tried Salix but never Slackware itself) even think the same for Salix. I don't doubt that there are a lot of derivative distributions that are like that, but well... Salix is definitely not like that.

The numbers that are shown here are for Slackware/Salix 14 .0 and the 32-bit repositories. For previous, or more recent releases (when they will be released) the numbers would probably be very similar. The 64-bit repositories should be the same as the 32-bit repositories (give or take a package). These numbers may also change a little in the course of each release's lifetime as security related packages are added to the patches directories etc, but only just a little.

Repositories


First of all, all of Slackware is in Salix. What I mean by that, is that every package that is included in the Slackware repositories, is available in Salix through the package manager (GSlapt from the GUI or slapt-get from the command line). There are a few exceptions, where we substitute Slackware packages for Salix-specific package, for several reasons that are very important to us, but that's it.

So, in terms of available pre-packaged software that you can find through the package manager in Salix, there is a total of 2145 packages. Of that, 1151 (53.7%) are original Slackware packages. The rest (994, 46.3%) are packages that were build for Salix and that you cannot find in Slackware repositories. Of course, Slackware users can install any of those packages if they like as every package is 100% compatible to Slackware. So, Salix almost doubles the amount of ready made software that a Slackware user can install.


Releases


So, what happens with Salix releases and the system that you get right after a fresh installation? The answer here varies, as Salix has several releases, based on different Desktop Environments and there are also different installation modes for each of those releases, Core, Basic and Full, respectively.

We'll take a look at our Xfce, KDE and our soon-to-be-released Ratpoison editions for version 14.0.

Keep in mind that the numbers listed below are what happens right after a fresh installation. If people install the multimedia codecs using our salix-codecs-installer tool (and most people would), the number of Salix packages would increase by about 50.


Core Installation


A Salix Core installation is exactly the same, no matter what iso image you used to make the installation.

After a Core mode installation, you get a total of 250 installed packages. Of those packages, the vast majority (233, 93.2%) are Slackware packages. The rest (17, 6.8%) are Salix-specific packages. The Salix packages are mainly the package manager, the Salix command line system tools and their dependencies and nothing more.

So, what you get with a Salix Core installation, is mainly a Slackware system that only works from the command line and only very few added packages by Salix. It's funny, because there are a lot of Slackware users that apparently look for a stripped down Slackware installation with no GUI, but never look at Salix.


Xfce Basic Installation


OK, so what happens once we start adding a GUI and all related packages. A Salix Basic installation adds only the Desktop Environment and very few graphical applications on top of it, like a browser, a graphical package manager and the Salix GUI system tools.

After an Xfce Basic installation, you get a total of 579 packages (including all the packages in the Core installation). 532 of those packages (91.9%) are pure Slackware packages. Still, only 47 (8.1%) are Salix specific packages. The number of Salix specific packages might still be small, but these few packages this time make a difference; among these packages there are packages that add important functionality, like the Salix GUI system tools or a login manager etc.


Xfce Full Installation


An Xfce Full installation is what most people would use though.

A total of 761 packages are installed (including all packages in the Core and Basic installations). Of those packages, 611 (80.3%) are Slackware packages and 150 (19.7%) are Salix packages. So, the Salix part becomes really significant here and among the Salix packages are some that are considered really important for a desktop distribution, like the LibreOffice suite, the media players, document/image viewers etc.


KDE Basic Installation


After a KDE Basic installation, you get a total of 626 packages installed. The number of Slackware packages is 580 (92.7%) and the number of Salix packages is 46 (7.3%). The numbers are similar to the Xfce Basic installation.


KDE Full Installation


A KDE Full installation includes a total of 760 packages. Of those, 661 (87.0%) are Slackware packages and 99 (13.0%) are Salix packages. The numbers are similar to the Xfce Full installation, only slightly skewed to the Slackware side, as KDE is a major part and the default DE for Slackware and a lot of KDE-related software is part of Slackware anyway.


Ratpoison Basic Installation


In a Ratpoison Basic installation, there is a total of 561 packages. Of those, 514 (91.6%) are Slackware packages and 47 (8.4%) are Salix packages. So, numbers are similar across all Basic installations.


Ratpoison Full Installation


A total of 672 packages are installed in a Ratpoison Full installation. The number of Slackware packages is 575 (85.6%) and the number of Salix packages is 97 (14.4%). The numbers are somewhere in between the Xfce and KDE Full installations.


Conclusions


Here is a table that sums up all the numbers mentioned above:
Total Slackware Salix
Repositories 2145 1151 (53.7%) 994 (46.3%)
Core 250 233 (93.2%) 17 (6.8%)
Xfce Basic 579 532 (91.9%) 47 (8.1%)
Xfce Full 761 611 (80.3%) 150 (19.7%)
KDE Basic 626 580 (92.7%) 46 (7.3%)
KDE Full 760 661 (87.0%) 99 (13.0%)
Ratpoison Basic 561 514 (91.6%) 47 (8.4%)
Ratpoison Full 672 575 (85.6%) 97 (14.4%)


It is obvious that the contribution of Salix to the Slackware ecosystem is significant. With Salix almost doubling the amount of packages that Slackware offers, it is the largest third-part package repository for Slackware out there. What's most important is that these packages are of very high quality, tested and guaranteed to work in a pure Slackware installation.

Moreover, the part that Slackware plays in every Salix release is apparent. What you get after a Salix installation, is really a stripped Slackware system, that includes all the extra parts that Salix provides to make it really usable.



Tuesday 22 October 2013

New website design!

As many might have noticed, we now have a new main website design!

Since the Salix project was started, the main website was actually a part of our wiki, which is using the MediaWiki engine. That had one main advantage, which at that time seemed enough to justify that choice; we would use a single CMS to manage both our wiki and our main page. So, we created a custom MediaWiki theme that would look good as a main project page and as a wiki. And admittedly, that worked fine for several years!

During the last months though, disadvantages started to become obvious. What happened first was that the latest updates to the MediaWiki software broke our custom theme. So, that meant that we should either fix that custom theme (which mostly meant writing it from scratch again) or separate the main page from the wiki and use the wiki with a standard MediaWiki theme. We went for the latter option as that was considerably less work! So, the wiki would look more like any other MediaWiki based wiki out there, but we were free to upgrade it to newer versions, covering security issues without thinking of what it will do to our main webpage.

That left us hunting for a system to manage our main page. The first option we tried was Pelican. It really looked like a good choice. The content was written in simple markdown and then using Pelican we would take that markdown and transform it into a full website that Pelican could also upload and sync to the main server. And what Pelican created was simple HTML content. No database was needed to run in the background and there was no PHP content anywhere. Nice and simple. The fact that the content was plain HTML, would mean that the website would be less prone to attacks. Also, the fact that kernel.org also used Pelican for managing their website was very reassuring too. So, we took the Pelican theme that kernel.org was using, tweaked it a bit and that looked good and very close to what we wanted!

The advantages of using such a system became apparent shortly after we switched. Unfortunately, we had hardware troubles with the server that hosted our main page, our wiki and our forums. The MySQL databases that the wiki and forum were using would become corrupted and the wiki and forums would stop working. It took us a while to realize that this was actually caused by a hardware problem. We first thought that it was a hard drive in the RAID array failing, but all hard drives passed any tests without problems. Then, since we were getting filesystem errors constantly, we thought that it may be the hard drive controller card, but that looked OK too. It turned out that the mainboard was faulty, so after a mainboard replacement, everything was back to normal again. But during all that time, the wiki and forum was mostly down, but at least our main page was working! The fact that it was only static HTML pages and it didn't need a database or any code for that matter running on the server made it work with no problems with even such severe hardware errors!

So, Pelican looked indeed like a very nice choice! And it worked nicely as our main page for a month or so. Serving static content is also a lot faster than serving a complex CMS, the main page would load a lot faster than before. But then trouble started again. I wanted to update some content on the main page. For generating the main page, we had originally used Pelican 3.0 and that was what I had installed on my laptop which I had used then. Unfortunately, I had forgotten that laptop at my parents house after a weekend visit and wasn't going to get it back for at least another couple of weeks. So, I went ahead and installed Pelican 3.3 at the laptop I actually had with me, which was now the latest version (and the one that was easier to install using pip). And then realized that everything was broken. The upgrade from Pelican 3.0 to 3.3, meant that the theme that we were using needed a major restructuring (possibly a complete rewrite) because it wouldn't work at all any more. So, we either had to do that, or switch to something different, once again. During all that time, it also became apparent that Pelican was mostly suited to writing blogs, instead of mostly static content which is what we wanted. It could create static content, but it's main thing is really blogs...

It was then that I remembered that I was already using a tool that could create simple, static HTML content using simple markdown. I was already using txt2tags to create man pages for all the system tools that you can use in Salix, but it can also create HTML pages too (among over a dozen other different output formats). So, maybe it was simpler to switch to txt2tags. And it was! txt2tags can be used to create simple HTML pages and those pages can look like anything you like, using CSS! That is an even simpler system than Pelican and closer to what we were looking for in the first place. The txt2tags website itself is written in txt2tags as are a number of other different websites which you can find on the txt2tags website. I liked the looks of the txt2tags website so much that I used exactly the same CSS, with only minor changes. So, that is why both pages look very similar.

In the spirit of Pelican, I created a simple Makefile that would help with generating the static HTML content and also with updating the main webpage with it. Everything is online in my github repo.

If in the future we decide to switch to a different look, it's just as simple as using a different CSS. Since the txt2tags syntax is highly unlikely to change, our main page is now beautiful, fast, more secure and future-proof!

I'd like to thank Thorsten for all his work with our wiki, forum and Pelican website. I'm mostly ignorant of how it all works...