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.
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.
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.
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.
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.