Posted by Diego "Flameeyes" Pettenò
Tue, 05 Aug 2008 13:55:00 GMT
I was reading Planet FreeBSD the other day and I noticed an intersting
post about PAM. It talks about a couple of old vulnerabilities in OpenSSH that allows to gather information about a system depending on the timing used for authentication.
As it turns out, the issues have been fixed a long time ago in OpenSSH portable so Gentoo is far from being affected by those, but the interesting part is that the issue is caused by the delay that Linux-PAM implements by default on failed login attempts.
As it turns out, I wonder now if there is a reason at all we enable that. I wonder because even if OpenSSH is fixed, similar problems may apply to other remote services that use PAM for remote authentication. One option I see is to enable the delay only on local logins, but that would require a bit of duplication in pambase, as it is. Or maybe it could be implemented through a pam_delay module.
The nice thing about pambase is that it takes very little time to actually get this updated, as I need just to update pambase package rather than the whole Linux-PAM, which is a mess to update.
And just to show one good thing about pambase, in the past days I added an sha512 USE flag to the package, with that enabled, the latest Linux-PAM version is brought in and SHA512 password hashing is enabled. This means that rather than using MD5 for encrypting the passwords in the shadow file, once you’ll change them they’ll be saved using SHA512. The advantage is that SHA512 should be more secure than MD5 (which I think is, nowadays, considered not secure anymore).
Before version 1.0.1 of Linux-PAM to achieve similar goals you had a few different options. You could have used pam_unix2 (which I think was used or developed by SUSE) or you could have used pam_sha512, otherwise you could have been using tcb to use blowfish encryption.
Now that the same result can be achieved with a single USE flag (and a single change to the PAM configuration), the sys-auth/pam_sha512 package is masked for removal, one less package to maintain in tree.
So at the end, pambase is coming along nicely, as I was hoping it would. This should be a very good way to handle future options and other increased securities without having to update the code behind at the same time.
Posted in Gentoo, Technical, English | Tags FreeBSD, LinuxPAM, OpenPAM, PAM, SHA512 | 2 comments
Posted by Diego "Flameeyes" Pettenò
Sun, 03 Aug 2008 14:16:00 GMT
Just a service announcement post for the few users following my blog. As the GMN is often reporting blog posts of mine that are more than a month old I decided to make some changes to how comments get disabled.
Up to today, posts older than 30 days had their comments section disabled, this is because after a while most of the comments arriving on these are just simple spam, and while I’m forced to premoderate the comments anyway (too much spam otherwise), I’d rather not having more of it to remove.
Now I moved the limit to 90 days, so there should be enough time to comment even when GMN posts a link a month later.
If you wanted to comment on a not-so-recent post of mine and you found the comments disabled, you might want to take a look now, as the change is retroactive.
If I don’t see an exponential amount in spam I might just as well leave all the posts enabled even after 90 days.. there’s time to see that ;)
Posted in Gentoo, Personal, English | Tags Blog, Comments, GMN | 3 comments
Posted by Diego "Flameeyes" Pettenò
Fri, 01 Aug 2008 11:00:00 GMT
So everybody says that CMake is great because it’s faster. Of course CMake achieves speed with an approach different from the one autotools have, that is, they don’t discover features, they apply knowledge. Hey it’s a valid method as any other, if you actually know what you are doing, and if you can keep up with variants and all the rest. Another thing that it does is to avoid the re-linking during the install phase.
Let me try to explain why re-linking exists: when you build a project using libtool, there might be binaries (executables and/or libraries) that depend on shared libraries that are being built in the same source tree. When you run the executables from the source tree, you want them to be used. When you install, as you might be installing just a subtree of the original software, libtool tries to guess if you just installed the library or not (often making mistakes) and if not, it re-links the target, that is, recreates it from scratch to link to the system library. In the case of packages built by ebuild, by the use of DESTDIR, we almost always have the relinking stage in there. Given that GNU ld is slow (and IMHO should be improved, rather than replaced by gold, but that’s material for another post), it’s a very wasteful process indeed, and libtool should be fixed not to perform that stage every time.
One of the things that the relinking stage is supposed to take care is to replace the rpath entries. An rpath entry specify to the runtime linker (ld.so) where to find the dependent libraries outside of the usual library paths (that is /etc/ld.so.conf and LD_LIBRARY_PATH). It’s used for non-standard install directories (for instance for internal libraries that should never be linked against) or during the in-tree execution of software, so that the just-built libraries are preferred over the ones in the system already.
So to make the install phase faster in CMake, they decided, with 2.6 series, to avoid the relinking, by messing with the rpath entries directly. It would be all fine and nice if they did it correctly of course.
I reported earlier a bug about cmake creating insecure runpaths in executables starting from version 2.6. Don’t panic, if you’re using Portage, it’s all fine, because the scanelf run that reports the problem also fixes it already. In that bug you can find a link to a discussion from April . The problem was known before 2.6.0 final was released, yet it was not addressed.
So it seems like someone (Alex) used chrpath first. That’s a good choice, there’s a tool out there that does what you need, use it. At the worse you use it wrong and you fix it fine.
But no, that’s not good enough for Kitware, of course, and Brad King decided to replace that with a built-in ELF parser (and editor). Guess what? Mr. King does not know ELF that well, and expected an empty rpath to behave like no rpath at all.
Try these simple commands:
% echo "echo Mr. King does not know ELF" > test-cmake-rpath
% chmod +x test-cmake-rpath
% PATH= test-cmake-rpath
An empty PATH adds the current working directory to it. Which means that the generated ELF files from CMake 2.6 would load any library that is in the current working directory that is named after one of the names in the NEEDED lines of itself and its dependencies. There are a few attack vectors exploiting those; not all of them are exactly easy to apply, most of them don’t cause root vulnerabilities but it’s still not good.
Now of course a mistake, or missing knowledge about a particular meaning of a value in an ELF file is nothing major. Myself I didn’t know about PATH= before a few months ago, but I did know an empty rpath was not good at least.
What is the problem then? The problem is that messing with an ELF attribute like rpath, without knowing ELF files, without knowing the behaviour of ld.so and even more importantly without asking to any of the QA team of any of the distributions out there (Gentoo is certainly not the only one who dislikes insecure rpath), is just not something that earns my trust. At all.
And even worse, if the original implementation used chrpath, why not leaving it at that? Given you don’t know enough about ELF files it sounds like a very good idea. It’s not like chrpath is a tremendously exotic tool to have around for distributions.
For your information, this is how chrpath behave, and how it’s difficult to actually misuse:
flame@enterprise mytmpfs % scanelf -r hellow*
TYPE RPATH FILE
ET_EXEC /tmp hellow
ET_EXEC - hellow-2
ET_EXEC hellow-3
flame@enterprise mytmpfs % scan
flame@enterprise mytmpfs % gcc -Wl,-rpath,/tmp hellow.c -o hellow
flame@enterprise mytmpfs % scanelf -r hellow
TYPE RPATH FILE
ET_EXEC /tmp hellow
flame@enterprise mytmpfs % cp hellow hellow-2
flame@enterprise mytmpfs % chrpath -d hellow-2
flame@enterprise mytmpfs % scanelf -r hellow-2
TYPE RPATH FILE
ET_EXEC - hellow-2
flame@enterprise mytmpfs % cp hellow hellow-3
flame@enterprise mytmpfs % chrpath -r '' hellow-3
hellow-3: RPATH=/tmp
hellow-3: new RPATH:
flame@enterprise mytmpfs % scanelf -r hellow-3
TYPE RPATH FILE
ET_EXEC hellow-3
And this is the easy fix:
flame@enterprise mytmpfs % scanelf -Xr hellow-3
TYPE RPATH FILE
ET_EXEC - hellow-3
Okay now at the end of the day, what can we do about this problem? Well in Gentoo we should disable this behaviour from CMake, let’s make it a bit slower, but safer; even if scanelf is covering our butts, it’s still a patching up something that someone else is continuously screwing up; and it opens the vulnerability when the users build without Portage.
And indeed, if you are building something with CMake 2.6, outside of Portage, you might also want to fix the rpaths of the installed executables and libraries, by issuing scanelf -RXr $path_to_the_installed_tree. Possibly after each time you rebuild your stuff.
To finish, a nice note that shows just how much caring people handling CMake in KDE are …. KDE trunk will require CMake 2.6 on August 4th . Nevermind there is an open security issue related to the code it builds.
Oh the irony, and they say I don’t give enough arguments why I don’t like CMake!
Posted in Gentoo, Technical, English | Tags CMake, ELF, KDE, KDE4, portage, RPATH, scanelf, Security | 11 comments
Posted by Diego "Flameeyes" Pettenò
Thu, 31 Jul 2008 14:29:00 GMT
As I wrote I’ll be trying to write more documentation about what I do, rather than doing stuff. This is because I’m simply too tired, and I should rest and relax rather than stress myself.
So after playing some Lego Star Wars I’ve decided to take a look to what I need to document for PAM. There was an easy bug to fix so I decided to tackle that down; tackling that down I decided to look if I was missing anything and I noticed that sys-libs/pam could use a debug USE flag. Unfotunately, not only it does not build with debug USE flag enabled, but it also fails with it disabled because the configure file was written by someone who yet again fail at using AC_ARG_ENABLE.
But this was just one of the two things I noticed today and I wished to fix if I didn’t have to rest, so I decided to write here a small checklist I follow when I have to check or fix packages:
- If the package is using autotools, I make sure they can be rebuilt with a simple
autoreconf -i. Usually this fails when macros are present in the m4 directory (or something like that), or if it misses the gettext version specification for autopoint.
- If the package supports out-of-sourcetree builds, I create an “enterprise” directory and build from there (usually it involves a
../configure). A lot of packages fail at this step because they assume that source directory and build directory are one and the same.
- If the package uses
assert() I make sure it works with it disabled (-DNDEBUG); this is usually nice to link to the debug USE flag to remove debugging code.
- I check the resulting object files with
cowstats (check Introducing cowstats for more information about this), and see if I can improve the situation with some trivial changes.
- I check the resulting object files with
missingstatic (another script in ruby-elf).
- If the package uses automake I make sure the
_LDFLAGS variables don’t contain libraries to link to (would break --as-needed).
- I check for possible bundled libraries we don’t want to use.
- I check for possible automagic dependencies that we don’t want in the ebuild.
- I run a build with all the useful warnings enabled, and see if there is something that needs to be fixed.
Such a checklist, if done from start to end, may generate a fair amount of patches that have to be sent upstream. It usually requires to check them on their development repositories too so that the patches are not obsoleted already.
As you can guess by now, it’s not exactly the quickest of the tasks, and it depends a lot on the power of the development box I’m working on. Unfortunately using a faster remote box does not always help because, even if Emacs’s tramp is quite neat, it does not make it easy to access the sources for editing. And having the sources locally and mounting them remotely doesn’t resolve either, as the build would then stall on getting the sources.
My plans were to get either the YDL PowerStation or a dual quad-core Opteron system (yes I know it’s overkill, but I don’t want to have to upgrade system every three years). It wouldn’t have been that bad, I just needed to take a couple of jobs during summer and early fall, and I could afford them. Right now, though, the situation looks pretty bad. I’m not sure whether I can get a new job done before fall, and even though medical care in Italy is paid for by the government, there are a few expenses I had to make (like for instance an over-quota for my Internet connection to download the software to view my CAT scans while I was in the hospital—long story, I’ll write about that another day), and the visit next Tuesday is in private practice (so I’ll have to pay for it).
If you care about a package, try to apply these checks on it, and see if upstream can pick up some improvements :) Every little drop is an advantage!
Posted in Gentoo, Technical, Personal, English | Tags autotools, Checklist, checks, cowstats, Ebuilds, ELF, Maintainership, missingstatic | no comments
Posted by Diego "Flameeyes" Pettenò
Thu, 31 Jul 2008 09:49:00 GMT
No I’m not working on C# again, although I admit i have Mono installed. Actually to be honest I’m not working on anything at the moment.
I have scheduled a visit in Verona next Tuesday, then they’ll probably tell me when I’ll have surgery, and which kind of surgery. Up to then I’m not sure how to organise myself with jobs and other things so I’ll probably keep a very low profile.
So, to make sure I don’t end up leaving packages unmaintained and bugs unseen, I’m trying now to delegate as much as I can of my responsibilities to other developers. Hopefully this way there won’t be anything left untouched while I’m convalescent.
The only things I’ll be working on this week, and even those only briefly, are short documentation updates, and maybe, but just maybe, version bumps. I already updated the --as-needed fixing guide trying to make it a bit more clear what to do with some errors, and how to properly filter the flag, and when to actually filter it. I’ll probably write something more about that, and then start seeing if I can write something about autotools update problems.
I’m doing this because multiple people (both devs and non) contacted me while I was in the hospital asking how to fix stuff, for --as-needed, new libtool, new autoconf, and so on. As I cannot really answer them while I’m in the hospital, I’d rather see to write a proper guide before I enter again, and then leave that to them as a reference.
I really can’t afford another pancreatitis, so I’ll have to reduce my stress levels a lot. Help with stuff I’ve been working on is very very welcome. So if you wish to spare some time and help me with, for instance, identifying packages that need to be fixed to work with OpenPAM, so that Seraphim’s work could be actually made good use of after it’s done.
Now I’ll cut this entry short, as I want to take care of other things today, like being able to play a bit (I haven’t played seriously in weeks!), plus I have to download from the camera some more photos I made this morning.
Again, donations to me, gifts, but even more importantly, day after day, to the research on pancreatic diseases are welcome.
Posted in Gentoo, Personal, English | Tags AsNeeded, Delegating, Documentation, Health, Maintainership, Packages, Pancreas, Stress | 1 comment
Posted by Diego "Flameeyes" Pettenò
Tue, 22 Jul 2008 17:45:00 GMT
After my previous post about preserved-libs feature, I was asked by many users if I was against this feature because it incremented the usability of Gentoo. I sincerely think I shown before that I don’t want Gentoo to remain for elitists, and thus I won’t be going to say nay to anything to make stuff easier to the users.
On the other hand, I want to make sure that users, excited about being able to upgrade stuff without breaking their system, won’t break it even further. For this reason I want to warn again users against trying the unstable Portage version (2.2) on their stable systems just yet.
Thanks to Zac and Marius, the problem I’m going to talk about is already being taken care of, so it won’t appear once 2.2 final will arrive. So why am I writing about this anyway? Well the reason is actually quite simple: future memory.
On the topic of linking, loaders, ELF files and all the things related, there isn’t a lot of documentation that is available to newcomers. Most of it is very technical and requires good knowledge of many concepts to be useful. I only know of a book that goes in deep of this, Rob Levine’s Linkers and Loaders is probably the most interesting reading on the subject ,as far as I can see. Unfortunately I haven’t tried converting the downloadable version in LRF to load it on the EBook Reader and I haven’t got the printed copy. I should probably get that too, as a reference, I’m just afraid that all the hardcopies I have here will remain at my parents’ house once I move out.
Okay, let’s return back on topic now. What is the problem I found today with preserved-libs? Well as I updated to Xorg 1.5 pre-releases to check if my RandR problems were fixed (by the way, they are), there was a libGL update. I also took the time to switch back to gcc 4.2 for a short time as I wanted to rebuild VirtualBox without ALSA support (whenever I can I’m using PulseAudio), and I could also rebuild xmlrpc-c (the reason why I couldn’t build this with GCC 4.3 is good for a different entry one day). After these builds, Portage told me this:
!!! existing preserved libs:
>>> package: media-libs/mesa-7.1_rc3
* - /usr/lib64/libGLU.so.1.3
* - /usr/lib64/libGLU.so.1.3.070003
>>> package: dev-libs/xmlrpc-c-1.06.27
* - /usr/lib64/libxmlrpc.so.3.6.4
I was surprised because I know libGLU rarely changes interface, and I didn’t think xmlrpc-c would have either. And indeed a quick scanelf run over the files confirmed my ideas:
flame@enterprise ~ % scanelf -S /usr/lib64/libGLU.so*
TYPE SONAME FILE
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1.3
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1.3.070003
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1.3.070100
flame@enterprise ~ % scanelf -S /usr/lib64/libxmlrpc.so*
TYPE SONAME FILE
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so.3
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so.3.6.15
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so.3.6.4
As you can see the soname for both the versions of libGLU and both the versions of libxmlrpc is the same. So there is no ABI break, and no good reason for the file to disappear, right?
Indeed if we focus solely on the xmlrpc-c case, the result of preserved-libs actions is that there is now an orphaned unused and unusable shared object:
flame@enterprise ~ % ls -l /usr/lib64/libxmlrpc.so*
lrwxrwxrwx 1 root root 19 2008-07-22 18:04 /usr/lib64/libxmlrpc.so -> libxmlrpc.so.3.6.15
lrwxrwxrwx 1 root root 19 2008-07-22 18:04 /usr/lib64/libxmlrpc.so.3 -> libxmlrpc.so.3.6.15
-rwxr-xr-x 1 root root 56864 2008-07-22 18:04 /usr/lib64/libxmlrpc.so.3.6.15
-rwxr-xr-x 1 root root 56368 2008-02-23 13:36 /usr/lib64/libxmlrpc.so.3.6.4
Let’s see, ld.so (the runtime linker) will look for a library with, as filename, the soname listed in a program’s NEEDED entry in the dynamic seciton of the ELF file. In this case, the soname of libxmlrpc is libxmlrpc.so.3 so that’s what the linker will look for. On my system, that filename is linked to the 3.6.15 version, so the runtime linker will always load the new version of libxmlrpc. The build-time linker (ld) looks instead for the filename with the simple .so prefix (or .a for static libraries). That one is also pointing to 3.6.15.
So who is using the 3.6.4 version that Portage preserved? Well, the only way to use it is to dlopen() it directly and accessing it that way. Which, if anything would be doing that, would be craziness, to the point that I’d rather not see such a software in my system at all. The other option is for an ELF file to have a tweaked NEEDED entry that points explicitly to the full version, but I can tell you I have none of those.
So for now I’ll simply remove the two files, and get rid of the problem. But as you can see, it’s too soon to expect preserve-libs to work out of the box in a perfect manner.
Anyway, Marius, Zac, please keep up with the good work, it’s really needed :) Thanks guys!
Posted in Gentoo, Technical, English | Tags ABI, ELF, Linking, portage, PreserveLibs | 5 comments
Posted by Diego "Flameeyes" Pettenò
Tue, 22 Jul 2008 14:24:00 GMT
For those of you who’d like to follow Google Summer of Code progress (I’d very much like to have the blogs of the student available on Universe by the way), today (or rather yesterday) can be counted in as a very important date :)
Seraphim prepared a patch for shadow (the package containing all the basic utilities for users management in Linux) to work with OpenPAM, rather than depending strictly on Linux-PAM. I committed it in tree now for 4.1.2.1 and upstream applied it to trunk already, so now it can be built even when using OpenPAM rather than Linux-PAM. Cool, eh?
This patch (and the related bug) are important not only because they fix a very important part of the functionality of a Linux system with OpenPAM, but also because it will act as a base reference to fix other software to use OpenPAM too.
Indeed, one of the most obnoxious problems with OpenPAM is that a lot of packages instead of writing their own conversation functions rely on misc_conv. Seraphim prepared a patch that can be applied to almost any other package relying on that to make it OpenPAM-compatible. It’s very good.
Unfortunately, as Seraphim also blogged there is one catch with being able to provide OpenPAM support, especially for the future. The problem is that although mostly API compatible, OpenPAM and Linux-PAM are not ABI compatible. Although in a very subtle way, because, as Seraphim learnt, you can have a system built against Linux-PAM run against OpenPAM just fine, up to a point.
The problem is that ABI does not only refer to the name of the functions, or the type of their parameters, but also to the meaning of flag values. In this case, Linux-PAM and OpenPAM give different flags different meanings, so modules built against OpenPAM will not work properly with software built against Linux-PAM.
This is going to be tricky, especially once we’ll allow users to switch from one to the other and vice-versa, because it means all the software will have to be rebuilt to continue functioning as it’s supposed to. And no preserved-rebuild will help us there.
Oh well, there’s time to think of that!
Posted in Gentoo, Technical, English | Tags Debian, GSoC, LinuxPAM, OpenPAM, PAM, patches, Shadow, SummerOfCode | 1 comment
Posted by Diego "Flameeyes" Pettenò
Mon, 21 Jul 2008 16:00:00 GMT
With my move to Gnome I decided to try out again the graphical login. I used to use standard console login before because KDM lacked too many features, and while for some time I kept using GDM, it just didn’t feel right. Unless I was going to just do some system administration, or testing PAM, the only command I was going to type was startx, followed by sudo shutdown -h once I was done.
To do so, I had to give up keychain, at least for inserting the private key’s passphrase. Instead of using that, I decided to change my PAM setup to use pam_ssh (and this is also what brought me to plan removal of pam_ssh_agent .. I just remembered I forgot to add that to the Gentoo Calendar!—done!), so that instead of typing my password and my SSH key passphrase, I just have to type in my passphrase at login and I’m done. The nice thing is that the standard Unix password is also accepted, so I can use that to take me out of the lock screen that Gnome applies when I walk away from the system, which is much shorter.
Again, I will probably put up a request for an electronic ID card next september and consider using a smartcard reader (I I wonder if I can use old, invalid, credit cards as smartcards too, once they are formatted).
So okay, I’ll write at another time about pam_ssh, it’s not what I’d like to write about right now.
With GDM I’m having one problem: my current setup is a dualhead, with a 16:10 monitor (and a 4:3) and using XRandR 1.2 (radeon driver). I have the screen disposition set up in my xorg.conf, but I’m not able to set the proper mode for the 16:10 monitor in the configuration file. If I set PreferredMode in xorg.conf, X11 refuses to start, without any apparent error either.
So for now I’m running at the session manager level two xrandr commands to set up properly the screens, but there is one problem: synergys does not seem to be expecting the geometry of the screens to change, so it still wraps my pointer out on the coordinates where it should have wrapped before the xrandr fixes.
I should probably see to try the latest masked version of xorg, and check if it works there. Although I think Synergy should have considered the case of changing screen layout. Maybe one day it will be rewritten using XCB and it will consider that problem too ;)
Oh yeah I should be writing about XCB too…
Posted in Gentoo, Technical, English | Tags GDM, GNOME, Synergy, Xorg, XRandR | 2 comments
Posted by Diego "Flameeyes" Pettenò
Sun, 20 Jul 2008 15:57:00 GMT
As it turns out, I start to dislike the way the KDE project is proceeding, and I don’t refer to the Gentoo KDE project, but to the whole of KDE project.
I dislike the way KDE 4 is being developed, with a focus on eyecandy rather than on features. This is easily shown by the Oxygen style; not only it is taking up a amount of screen real estate for widgets that remind me of Keramik (and if you remember, one thing that made happy a huge amount of users was the switch from Keramik to Plastik as default style in KDE 3.3), but it’s also tremendously slow. And I’m sure of this, it’s not just an impression: as soon as I switch Qt to use Oxygen, it takes five seconds for Quassel to draw the list of buffers; once I use QtCurve, it takes just one second. I don’t know if this is because Enterprise is using XAA and not EXA, but it certainly doesn’t look like something that the default theme should do.
And no, I’m not expected to use a computer that has less than an year, with a hyper-strength gaming videocard to be able to use KDE.
But this is just one of the issues I have with KDE recently. There are some policies I really, really, dislike in KDE. The first is one I already mentioned quite often and it’s the move to CMake. The only “good” reason to move to CMake is to be able to build under Windows using Microsoft’s Visual C++ compiler; yet instead of just saying “we needed cmake because it’s necessary to build for Windows” I see so many devs saying “cmake is just better than everything else out there”. Bullshit.
The other policy that I dislike regards the way KDE is developed and released as a single, huge, monolithic thing. One of the things that made KDE difficult to package in Gentoo (and other source-based distributions) was the fact that by default the source has to be built in those huge amorphous packages. And if the autotools-based build system of KDE sucked so much, it was also because of that.
But even if we leave alone the way the releases are made, it’s just not possible for everything to fall into a single release cycle kind of thing. There are projects that are more mature and projects that are less. Forcing all of them in a single release cycle makes it difficult to provide timely bugfixes for the mature projects, and makes it impossible for the not-so-mature projects to be tested incrementally. The last straw I could bear to see because of this stupid way of releasing, was knowing that Konversation in KDE 4 will probably lose the IRC-over-SSL support because KSSL was removed from the base libraries.
And now KDE 4.1 is on the verge of release, and Kopete still segfaults once you connect to Jabber. Yet when I tried (multiple times) to gather information about the possible cause in #kopete (so I could at least try to debug it myself), I had no feedback at all; maybe it’s because I run Gentoo, although the same happens on (K)Ubuntu. Yeah not the kind of people I like to deal with.
I’m not saying that I think Gnome is perfect for policies and other things. I dislike the fact that it’s always more Linux-/Solaris-centric than cross-platform centric; but I think KDE4 was a set back for that too, for what I read. And their release method does look a lot more sane.
I started using Linux with KDE 2. I moved to Gnome once KDE 3 was being taken care of. I came back to KDE just a bit before 3.3 release. Now I’m going to try Gnome for a while, and if I like it, I’ll think more than twice before going back to KDE. Yeah sure I liked KDE 3 better than I liked Gnome before that, but it’s just not feasible that I have to switch DE every time they want to make a new release.
Besides, since I last used it, Gnome seems much more mature and nicer to deal with.
Posted in Gentoo, Technical, English | Tags CMake, GNOME, KDE, Oxygen, Policies, Problems, Release | 29 comments
Posted by Diego "Flameeyes" Pettenò
Fri, 18 Jul 2008 16:27:00 GMT
I started using iSCSI a few months ago to be able to extend the capacity of my Windows XP virtual machine and Bootcamp with a shared partition. Using a partition on real hardware on the external Hard Drive was not an option as Parallels broke my Bootcamp more than once, and that is tremendously annoying. After that I started using it to share the external HD I bought for the laptop, so that it’s accessible from any place in my house, albeit slowly because it’s accessed through wireless.
Unfortunately the road for iSCSI target support on Linux ain’t exactly bump free. Updating to glibc 2.8 broke the userland tools of iscsitarget, and it took me a fair day to find a way to fix those. With the latest update to Linux 2.6.26, instead, it was the kernel module to (obviously) break.
This time the subversion repository of iscsitarget was updated already, so I decided to just take a snapshot of the repository, so I could get the actual fix from upstream for the glibc 2.8 issue and the fixes for the new kernel. I suppose I could start maintaining iscsitarget myself now ;) Thanks to Nataniel Copa the snapshot also provides a POSIX-compatible init script, which should make it possible to use it with OpenRC and dash. And guess what my alternatives idea would also make easy to do?
Okay so, the problem with the kernel module has been resolved, everything’s fine then? I wish.
The other problem I’m having now is related to another module that failed to build: madwifi-ng. Enterprise is currently connected to the main router through WiFi, using an Atheros 5K-based card (it’s a D-Link card). Now, as madwifi failed to build, I checked the kernel to see whether there was already an alternative in-kernel official driver for this card, and it turns out there is one, Ath5k, that seemed promising. It uses the mac80211 framework and does support my chipset. Cool.
Unfortunately after enabling it (and having it working fine at the first glance) it started disconnecting immediately, causing the connection to stall, and requiring a few restarts. After a few tries I can tell for sure that the problem is related to iSCSI. As soon as Time Machine on the Mac starts to kick in (it works on the iSCSI disk), the connection is lost:
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:14:7c:ba:a7:2e
wlan0: association frame received from 00:14:7c:ba:a7:2e, but not in associate state - ignored
wlan0: RX authentication from 00:14:7c:ba:a7:2e (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:14:7c:ba:a7:2e
wlan0: RX AssocResp from 00:14:7c:ba:a7:2e (capab=0x461 status=0 aid=2)
wlan0: associated
wlan0: switched to short barker preamble (BSSID=00:14:7c:ba:a7:2e)
wlan0: No ProbeResp from current AP 00:14:7c:ba:a7:2e - assume out of range
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:14:7c:ba:a7:2e
wlan0: RX authentication from 00:14:7c:ba:a7:2e (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:14:7c:ba:a7:2e
wlan0: RX ReassocResp from 00:14:7c:ba:a7:2e (capab=0x461 status=0 aid=2)
wlan0: associated
wlan0: switched to short barker preamble (BSSID=00:14:7c:ba:a7:2e)
For now I resolved connecting the laptop to Enterprise through the Gigabit interface, so that the iSCSI traffic does not pass through wlan0.
I’ll be going out with some friends in less than an hour, so the problem will have to wait till Monday (tomorrow I have friends coming over, and I have different plans for Sunday if I can avoid fixing this for now).
I’m not sure if I should be switching back to madwifi-ng (from SVN unless they release a new version to fix 2.6.26) or if I should report the problem to the kernel developers to see it fixed.
On different notes, yet still related to the kernel, I decided to make some changes to my configuration of the kernel with this release. I switched from the old “good” VesaFB to UVesaFB, even though I didn’t want to use an initramfs image, it works fine and it finally let me see the console decently on my 16:10 monitor (I start to wish I could have two of these rather than one being a 4:3 still… they come useful to have double windows in Emacs with source and header). I also removed the V4L subsystem and the support for BTTV as I removed the TV card from Enterprise, after hmmm more than five years of almost uninterrupted service; I’m using satellite (Sky Italia) in my room nowadays, so I don’t need the card here, I don’t even have the aerial connection in my office anymore.
I want to check if I’m building and loading stupid stuff. I found myself with the nvram driver enabled, yet not loaded at all, I wonder why I had it on at all. I obviously cannot remove the FireWire subsystem (the external HD I talked about before is using FireWire). I hate to have two SATA controllers enabled too, with two different drivers. I hope that, once I get a new box, all four the drives will stay on a single AHCI-enabled controller. I have two ethernet drivers too, the e1000 I use for iSCSI and the skge for the testing/development rig; and two soundcards, the integrated VIA82XX that right now I’m not using at all, and the ICE1712 I actually use. I haven’t disabled the VIA because I’d liek to use that for Skype once I get some decent headphones/mic set.
So anyway, I’ll better get going or I’ll be late again. What happened to me? I was never late before, I’ve started being quite late in the last weeks..
Posted in Gentoo, Technical, English | Tags Alternatives, ATH5K, Atheros, drivers, ietd, iSCSI, iSCSI_Target, kernel, Linux, WiFi, Wireless | no comments
