A look at Fedora 17

I had briefly tried Fedora 17 two weeks ago, but I cut that short so as to install the opensuse 12.2 Beta1 on my test machine.  With development of 12.2 now bogged down, I have reinstalled Fedora 17.  With the experience from the prior Fedora install, this mostly went well.


I downloaded the live KDE iso (intended for a CD) and wrote it to a USB thumb drive, from which I would install.  Booting the USB got me into a live Fedora session, running the KDE desktop.  Unfortunately, this version of KDE does not seem to like the ATI graphics card in my test machine, so the desktop session was not fully functional.  Some component (probably the window manager) died when I opened the first window.  I had expected this from my experience of two weeks earlier, so I knew that most things worked as long as I did not need the title bar on windows.  So I pressed on, regardless.

The main screen had an icon for “install”.  I clicked on that.  The installer started.  One of the first things it did was ask for the crypto key for my encrypted LVM.  My attempts to type in the key failed.  It was as if the mouse focus was somewhere else.  That was my only significant problem during install.  Attempts to use the “back” key to back up and retry did not help.  I could not kill just the installer, because of the problem of missing title bars.  So I used CTRL-Backspace to kill the Xorg session.  Then I logged in again (as “liveuser” with no password required), tried the installer again.  This time, all went well.

In the partitioning section, I chose custom partitioning.  I was able to select the volumes from within the encrypted LVM for install, with a separate small partition (“/dev/sda1”) to use for “/boot”.  The one thing missing, compared to an opensuse install, was that there was now way that I could specify Windows NTFS partitions for mounting in the fedora system.

For booting, the installer wanted to use the MBR.  But I was able to tell it to install grub in “/dev/sda1” which is where I prefer it.  After that, installation proceeded.  There was no software selection system, because an install from a live CD image just copies what is installed on the CD (or, in my case, USB).  The installer screen was not very informative about what was happening.

At the end of the install, it prompted for a reboot.  I did not want to reboot at that stage.  I happen to know that this computer will shutdown without problem, but hangs on reboot.  (It actually rebooted just fine when testing Archlinux, but hangs with fedora or with opensuse).  The installer seemed to have grabbed the mouse, so that I could not get another command in.  I tried CTRL-ALT-F3, and that gave me a virtual terminal login.  I logged in there as root, and did a “shutdown -h now”.

I then booted up the machine into Fedora.  I was prompted to define a user for the new system.  And there was an option to give that user administrative privileges (which I did).  The admin privilege is membership of the “wheel” group.  When that was done, I could login as that user.

First experiences

When I logged in, I had problems.  This was expected, due to the fact that this KDE version does not like my graphics card.  I then edited “.profile” and added:
That tells the graphics library to be a bit more conservative in what it does.  With that in the enviroment (after a logout and login), KDE started to behave consistently.  I could now use the title bars on windows.


This is a security component (security enabled linux).  Or maybe it is really a torture machine.  It seems to cripple sensible use of the computer.  I have not yet disabled it, but I may do that before long.

One of the first things that I had done after login as the administrative user, was to pull up the application for “users and groups”, and define two additional user accounts.  One of these was to be the account that I would normally use for most of my non-administrative work, with the other a test account for experimentation.  It turned out that these two accounts were unusable.  Access was blocked by “selinux”.  I’ll give RedHat a failing grade for that.  If I setup users with their defined interface, then that ought to create whatever selinux rules are needed for those user accounts to be accessible.

I logged back in as the adminstrative user.  An selinux error message showed up there.  And fortunately, it gave sufficient hints to solve the problem.  I had to “touch /.autorelabel” then reboot.  That causes selinux to reconfigure itself (which takes a while).  After that my new users could login.

I later ran into another problem with selinux.  I installed “ecryptfs”.  The installer nicely set things up so that ecryptfs would decrypt and mount the private files during login.  Unfortunately, somebody forgot to tell “selinux” that this is okay.  So now, when I login as my normal user account, I have to manually run “ecryptfs-mount-private” to access the data.  And when I login to the administrative account, I see a bunch of selinux messages about ecryptfs being blocked.  By contrast, the “apparmor” security application on opensuse has mostly worked quite well, with the one minor problem being corrected by a later update.

Network Manager

Setting up WiFi went very smoothly.  This was one place where Fedora is easier to use than opensuse.  I was never prompted for the root key when setting up a connection.  I thought that this might be because I set it up using that administrative account.  However, I had made that a system connection.  And I was able to edit the connection, including the key, from my normal (non-administrative) user account, again with no prompt for the root password.  The opensuse settings are too restrictive, though perhaps the Fedora settings are too lenient.  The modification that I made last week (access from those in the “network” group) seems a good compromise.

Software management

The “apper” application was available for updates and for adding new software.  A little while after getting the network running, a tray icon told me that there were some large number of updates – that turned out to be 184 updates after adding those needed for dependencies.  Clicking on that icon brought up apper..  I checked the box to select all, then clicked “Apply”.  A short while later, it again told me that there were 184 updates.  I repeated the procedure, and watched more closely.  It looked as if an error window popped up, but disappeared before it could be read.  Then the cycle repeated.  Sigh!

I unselected all of the updates.  Then I selected just the update for “apper” itself.  After clicking reply, it went ahead and did that update without the same looping.  I followed the advice to logout then log back in.  Then I opened apper to try some more.  It seemed to hang.  It looks as if apper can be used for updates only once.  Thereafter, you will have to reboot before using it again.

I rebooted, then tried apper.  This time, I selected a handful of updates and applied them.  That seemed to work.  I rebooted and repeated a couple of times.  By then, the count of needed updates was down to 108.  So I tried doing all of those in one run.  And, fortunately, that worked.

One more reboot for safety.  Then I went about installing some other software that  I normally use.  I installed “rcs”, “nmh”, “csh” and “ecryptfs”.  That seemed to go fine.

Since “synaptiks” was not installed, I tried that.  The search for it failed.  It seems that “synaptiks” is not in the Fedora repos.  Sigh!  I really like synaptiks.

Using SSH

I depend a lot on ssh for copying between machines.  So, naturally, I wanted to set it up.  So I edited the config files to my liking.  Then I tried to start the service.  While logged into the administrative account, I tried the “Services” application.  Unfortunately, it did not mention ssh.

The next step was a google search on the web.  That gave me the necessary commands:

systemctl enable sshd.service
systemctl start sshd.service

I used “su” to become root, and ran those commands.  They looked to have worked.  But I was unable to connect from another machine.  That looked like a firewall problem.  I checked the firewall settings, and those showed that “ssh” was already set as a trusted application.  So there should not have been a problem.

After some head scratching and web searching, I added access to port 22.  That did the trick.  It should not have been needed.  It looks as if Fedora came with a raw (text format) firewall configuration and a compiled configuration, but the two did not match.  It probably would have sufficed if I had unchecked the box for “ssh”, the checked it again.  That would probably have made the “apply” button accessible, and clicking that would have recompiled the rules and fixed the problem.


There is still a lot that I have not yet tested, so this is a preliminary evaluation.

Overall, Fedora looks to be a pretty good system, though that might require disabling “selinux”.  It is a system I could get along with quite well, though I would miss synaptiks.  However, it does have me appreciating opensuse all the more.


Tags: , , , , ,

About Neil Rickert

Mathematician and computer scientist who dabbles in cognitive science.

5 responses to “A look at Fedora 17”

  1. Neil Rickert says :

    Since posting this, there has been an update to “ecryptfs”, which seems to have corrected the problems mentioned. That is to say, SElinux is no longer blocking “ecryptfs” so that my Private filesystem is properly mounted as decrypted during login.


  2. Neil Rickert says :

    A second update.

    I downloaded the DVD image, and decided to a fresh reinstall from that (again, via a USB stick rather than a real DVD). I installed KDE, Gnome, XFCE and LXDE as desktop environments.

    With that DVD install, some of the earlier problems vanished. I was able to create a couple of user accounts with the provided administrative tool. And those accounts worked immediately, with no SELinux problem. The firewall settings for SSH worked. There was no longer a discrepancy between what the firewall rules said and how the firewall actually behaved.

    One problem that did remain, was with applying updates with “apper”. Because I had installed more software, this time I found that there were 324 updates to be applied. I attempted to apply all at once (the default apper behavior), though I expected that to fail. And, indeed, it did fail. I then went through the list and selected around 50 updates to apply. By the time the dependency check had finished, that list grew to around 60. Those applied without problem. I rebooted, and then repeated for another 50 or so. It is a bit tedious, but I did get all of the updates applied.


    • M.A. says :

      I just use Apper to see the updates and the reason for them (for example, the related CVEs if it is a security update). But for applying them, I open a terminal and su -c “yum update”. Works like a charm, every time.


      • Neil Rickert says :

        That’s what comes with me not being sufficiently familiar with the Fedora way of doing things.

        Thanks. I’ll give that a try for the next bunch of updates. They seem to come quite frequently, though not in large enough numbers to confuse Apper.


Trackbacks / Pingbacks

  1. Fedora 18 – a preliminary look « Thoughts on computing - 2013/01/17

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: