Archive

Posts Tagged ‘Debian’

GUI Failure

October 14th, 2009 No comments

Now that I’m running the Testing repositories, I actually get regular updates. Today, there were 15 available for my system. However, when I started the update manager, I was confronted with this dialog:

Screenshot-Upgrade-Fail

Well what the hell does that mean, anyway? Does it mean that the safe-upgrade will not remove any existing packages or install any new ones? Or is it asking if I would like to perform a safe-upgrade as opposed to installing new packages? Should I just click the Yes button, because it is green and the No button is red? Am I even seeing the correct colours? I am colourblind, you know. Furthermore, if I don’t understand what’s happening here, where can I get more information? How come, no matter what I choose, the Apply button on the next screen is disabled until I manually clear and re-select every update in the list? Lastly, how come the entire update manager crashes when I hit the Check button? It seems unable to resolve one of the sources in my list (one that doesn’t even appear in my /etc/apt/sources.list file), and instead of timing out, sits, waiting, presumably forever, no matter how many times I hit the Cancel button. I’m a seasoned computer user with well over a month of Linux under my belt and I’m concerned – what of those other users who don’t know shit about shit? I want blood, damnit!

/rant.




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

XFCE: A Bitch Session

October 14th, 2009 10 comments

After a full day of using XFCE as my new desktop environment, I have just a few complaints, handily summarized in the following ordered list:

  1. No Alt-Tab: I was under the impression that alt-tab window switching was a standard feature of every desktop environment since at least Windows 98. So where the hell is it in XFCE? Nowhere! That’s where! Instead, I enabled the ring switcher plugin for Compiz, which I had to run in order to use GNOME Do anyway.
  2. Default Browser Doesn’t Save: This one started out with the crappy default web browser that comes with XFCE, Web Browser 2.26.3. It is allegedly a GNOME project (which is odd to say the least, since this is XFCE, and GNOME defaults to the Epiphany Browser). In any case, even after setting the default browser to Firefox (Iceweasel in my case), the system still launches all links in this inferior app.
    Screenshot-Preferred Applications
  3. Cursor Set Doesn’t Apply Immediately: Along with changing the default web browser for my system, I changed the cursor set. The default one was ugly, so I grabbed some new ones from Synaptic, and set one in the mouse theme options dialog. The problem is that the cursor set doesn’t change until some random amount of time has elapsed after I log on. So my session begins with the old, ugly cursors, and then eventually gets around to changing over to the prettier new ones. What the hell?
  4. GNOME Do and Screenlets Don’t Always Start: This one is likely related to running Compiz on top of XFCE (which includes it’s own compositing engine), and the order of startup applications. In any case, sometimes when I log on, GNOME Do and Screenlets fail to start, and I have to bring them up manually. I have a feeling that this is because Compiz hasn’t yet started, and the applications fail, as they rely on it being there. Still, a hearty WTF to this one as well.
  5. Default File Browser Lacks Network Locations: The XFCE default File Manager is Thunar 1.0.1, which is fine, except that it does not include any way to browse network shares. In GNOME, I can hit the ‘Network’ place, and immediately view any available SMB share drives on my local network. As of yet, I haven’t figured out how to find or mount network locations through the XFCE GUI.
  6. The ‘Start’ Menu Fails: I never thought that I would say this, but I find myself longing for the Applications/Places/System menus of GNOME, instead of the mashed together start menu that is present under XFCE. Although this could just be because I’m not yet familiar with XFCE, I find it harder to locate programs in this menu system. The GNOME organization just felt more logical once you got used to it.
  7. Lack of Default Features: This speaks mostly to the organization of XFCE. Instead of including every imaginable feature in the default install, extra features are added through a series of plugins, so as not to bog down machines that don’t require them. As such, my default install did not include a battery level indicator, a wireless network strength monitor, or a slew of other ‘basic’ desktop environment features. Installing the package xfce4-goodies fixed all of these problems.

Of course, not everything about XFCE is bad. So far, I’ve found it to be stable and exceedingly fast. X11 hasn’t crashed once, although I have no doubt that it will; and once I installed the xfce4-goodies package, I found the environment to be very functional. Overall, I am pleased with my choice, even though there have been some minor setup annoyances.




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

Testing out Testing

October 13th, 2009 No comments

With everybody switching up their desktop environments this week, I decided that I’d take a shot at installing XFCE on my system. My initial research showed that it is somewhat like a light-weight, highly customizable GNOME. Since I’m running on older hardware, it seemed like the best choice for me. While at it, I also decided to go ahead and move my Debian install from the stable to the testing repositories. In an ideal world, this switch would open the doors to some newer software, alleviating many of the issues that I have had with older software.

Moving to Testing:

Without bothering to do any research, I added the Debian Testing repository to my sources list and told the machine to check for available updates. It immediately found 655 new packages available for installation. Luckily, Debian offered me a handy “Smart Upgrade Manager” and I didn’t have to navigate the upgrade process myself:

Screenshot-update-manager

After hitting the Smart Upgrade button, my machine chugged away for a few moments, figuring out dependencies and the like, and finally presenting me with a 1289.4MB list of 1570 required packages. Hoping for the best, I hit Apply, and spent the next 2 hours waiting for the necessary downloads to complete. Three episodes of House and an episode of Flashpoint later, at almost 1am, the install process was finally finished. So far, everything seemed alright.

Until I restarted. With the updates applied, my machine booted just fine, and even allowed me to login. Unfortunately, it never made it as far as the desktop. I was presented with a blank grey screen and a mouse pointer (which does work), but no windows, toolbars, or panels to speak of. It seems then, that X11 is working, but that it isn’t launching a window manager of any kind on login. I hit ctrl+alt+F1 and was relieved to find that I still had a terminal, and access to all of my files. But where did my desktop go?

Once at the terminal, I launched Aptitude, to see if there were some broken packages that needed to be fixed. It listed 190 that ought to be removed, and another 6 that ought to be upgraded, including GNOME. Hoping to fix the problem, I told it to get to work, and watched as it attempted to clean up the mess that I had created. That finished, I did what I should have done in the first place, and followed these instructions in an attempt to fix my system by upgrading properly.

This time, everything worked nicely, and within minutes, I was looking at my desktop through the brand spanking new GNOME v2.28.0, just released on September 27th. A solitary hiccup with dependencies required me to completely remove and reinstall the Compiz compositing engine. Friends, I speak to you now from the bleeding edge of the Debian GNU/Linux experience. From this point onward, I will receive the very latest code, just as soon as all release-critical bugs have been addressed. Sweet.

Adding XFCE:

From my newly stable machine, I opened up Synaptic package manager and installed the xfce4 package, which pulled all of the necessary components of my new desktop in as dependencies. I also added the xfce4-artwork package, as it promised a slew of extra pretty desktop backgrounds to play with. After adding Gnome Do, Docky, and playing around with the desktop settings, I arrived at a pretty decent looking desktop:

xfce-desktop

My first impressions of the desktop are that it seems very solid, fast, and customizable. Unfortunately, it is lacking a few creature comforts, mainly alt-tab window switching (seriously, what the fuck?), and drag-and-drop from menu items to  other windows. Over the next couple of weeks, I’ll give it a solid run, and see if it will become my Desktop Environment of choice.

Edit: After a long look down the tubes, I concluded that XFCE doesn’t support alt-tab, and just enabled the Ring Switcher plugin for Compiz to do the job instead.




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

Blackbery Sync Attempt #3: Compiling from Source

October 5th, 2009 7 comments

After my first two attempts at getting my Blackberry to sync with Mozilla Thunderbird, I got pissed off and went right to the source of my problems. I emailed the developer of the opensync-plugin-mozilla package that (allegedly) allows Thunderbird to play nicely with OpenSync, and gave him the what for, (politely) asking what I should do. He suggested that I follow the updated installation instructions for checking out and compiling the latest version of his plugin from scratch instead of using the older, precompiled versions that are no longer supported.

I set to it, first removing all of the packages that I had installed during my last two attempts, excluding Barry, as I had already built and installed the latest version of its libraries. Everything else, including OpenSync and all of its plugins went, and I started from scratch. Luckily, the instructions were easy to follow, although they recommended that I get the latest versions of some libraries by adding Debian’s sid repositories to my sources list. This resulted in me shitting my pants later in the day, when I saw 642 available updates for my system in Synaptic. I figured out what was going on pretty quickly and disabled updates from sid, without ruining my system. If there’s one thing that Windows has taught me over the years, it is to never set a machine to auto-install updates.

Once I had the source code and dependency libraries, the install was a snap. The plugin source came with a utils directory full of easy to use scripts that automated most of the process. With everything going swimmingly, I was jarred out of my good mood by a nasty error that occurred when I ran the build-install-opensync.sh script:

CMake Error at cmake/modules/FindPkgConfig.cmake:357 (message):
None of the required ‘libopensync1;>=0.39′ found
Call Stack (most recent call first):
cmake/modules/FindOpenSync.cmake:27 (PKG_SEARCH_MODULE)
CMakeLists.txt:15 (FIND_PACKAGE)

CMake Error at cmake/modules/FindOpenSync.cmake:46 (MESSAGE):
OpenSync cmake modules not found.  Have you installed opensync core or did
you set your PKG_CONFIG_PATH if installing in a non system directory ?
Call Stack (most recent call first):
CMakeLists.txt:15 (FIND_PACKAGE)

It turns out that the plugin requires OpenSync v0.39 or greater to be installed to work. Of course, the latest version of same in either the Debian main or lenny-backports repositories is v0.22-2. This well-aged philosophy of the Debian Stable build has irked me a couple of times now, and I fully intend to update my system to the testing repositories before the end of the month. In any case, I quickly made my way over to the OpenSync homepage to obtain a newer build of their libraries. There I found out not only that version 0.39 had just been released on September 21st, and also that it isn’t all that stable:

Releases 0.22 (and 0.2x svn branch) and before are considered stable and suitable for production. 0.3x releases introduce major architecture and API changes and are targeted for developers and testers only and may not even compile or are likely to contain severe bugs.

0.3x releases are not recommended for end users or distribution packaging.

Throwing caution to the wind, I grabbed a tarball of compilation scripts from the website, and went about my merry way gentooing it up. After a couple of minor tweaks to the setEnvOpensync.sh script, I got the cmpOpensync script to run, which checked out the latest trunk from the svn, and automatically compiled and installed it for me. By running the command msynctool –version, I found out that I now had OpenSync v0.40-snapshot installed. Relieved, I headed back to my BlueZync installation. This time around, I managed to get right up to the build-install-bluezync.sh script before encountering another horrible dependency error:

– checking for one of the modules ‘glib-2.0′
—   found glib-2.0, version 2.16.6
— Found GLib2: glib-2.0 /usr/include/glib-2.0;/usr/lib/glib-2.0/include
— Looking for include files HAVE_GLIB_GREGEX_H
— Looking for include files HAVE_GLIB_GREGEX_H – found
— checking for one of the modules ‘libxml-2.0′
—   found libxml-2.0, version 2.6.32
— checking for one of the modules ‘libopensync1′
—   found libopensync1, version 0.40-snapshot
— checking for one of the modules ‘thunderbird-xpcom;icedove-xpcom’
—   found icedove-xpcom, version 2.0.0.22
—     THUNDERBIRD_XPCOM_VERSION 2.0.0.22
—     THUNDERBIRD_VERSION_MAIN 2
—     THUNDERBIRD_XPCOM_MAIN_INCLUDE_DIR /usr/include/icedove
—     NSPR_MAIN_INCLUDE_DIR /usr/include/nspr
—     THUNDERBIRD_XPCOM_LIBRARY_DIRS /usr/lib/icedove
—     THUNDERBIRD_XPCOM_LIBRARIES xpcom;plds4;plc4;nspr4;pthread;dl
— checking for one of the modules ‘sunbird-xpcom;iceowl-xpcom’
—   found iceowl-xpcom, version 0.8
SUNBIRD_INCLUDE_DIRS /usr/include/iceowl;/usr/include/iceowl/xpcom;/usr/include/iceowl/string;/usr/include/nspr
SEVERAL
—      SUNBIRD_MAIN_INCLUDE_DIR /usr/include/iceowl
—      SUNBIRD_VERSION 0.8
— Found xpcom (thunderbird and sunbird):
—   THUNDERBIRD_XPCOM_VERSION=[2.0.0.22]
—   SUNBIRD_VERSION=[0.8]
—   THUNDERBIRD_VERSION_MAIN=[2]
—   SUNBIRD_VERSION_MAIN=[0]
—   XPCOM_INCLUDE_DIRS /usr/include/nspr;/usr/include/icedove;/usr/include/icedove/addrbook;/usr/include/icedove/extensions;/usr/include/icedove/rdf;/usr/include/icedove/string;/usr/include/icedove/xpcom_obsolete;/usr/include/icedove/xpcom;/usr/include/icedove/xulapp;/usr/include/iceowl
—   XPCOM_LIBRARY_DIRS /usr/lib/icedove
—   XPCOM_LIBRARIES xpcom;plds4;plc4;nspr4;pthread;dl
—   SUNBIRD_VERSION 0.8
CALENDAR_VERSION=[8]
LIBTBXPCOM_INCLUDE_DIR
XPCOM_LIBRARIES  xpcom;plds4;plc4;nspr4;pthread;dl
ENABLE_TESTING [yes]
TESTING ENABLED
— checking for one of the modules ‘check’
CMake Error at cmake/modules/FindPkgConfig.cmake:357 (message):
None of the required ‘check’ found
Call Stack (most recent call first):
cmake/modules/FindCheck.cmake:27 (PKG_SEARCH_MODULE)
CMakeLists.txt:73 (FIND_PACKAGE)

CMAKING mozilla-sync 0.1.7
— Configuring done

From what I can gather from this output, the configuration file was checking for dependencies, and got hung up on one called “check.” Unfortunately, this gave me zero information that I could use to solve the problem. I can verify that the install failed by running msynctool –listplugins, which returns:

Available plugins:
msynctool: symbol lookup error: msynctool: undefined symbol: osync_plugin_env_num_plugins

Ah, shit. Looks like I’m stuck again. Maybe one day I’ll figure it out. Until then, if any of our readers has ever seen something like this, I could use a couple of pointers.

Barry: Round Two with the Blogosphere riding Shotgun

September 30th, 2009 2 comments

Given the problems that I’ve been having lately with getting my Blackberry calendar and contacts to synchronize with anything in Linux, I was quite surprised when I almost got it working tonight. Forgetting everything that I’ve learned about the process, I started over, following these helpful tutorials and working through the entire install from the beginning. Unfortunately, aside from some excellent documentation of the install process (finally), the only new idea that those blogs provided me with was to try syncing the phone with different pieces of software. Specifically, Chip recommended KDEPIM, although I opted to  jump through a few more hoops before giving in and dropping the Thunderbird/Lightning combination entirely.

After a bit more mucking about, I decided to give up Lightning and installed Iceowl, Debian’s rebranding of Mozilla Sunbird, instead. Iceowl is the standalone calendar application that Lightning is based on, and is a very lightweight solution that is supposed to cooperate with the opensync-plugin-iceowl package. In theory, this allows calendar data to be shared between my device and the Iceowl calendar after configuring the plugin to read my Iceowl calendar from the /home/username/.mozilla/iceowl/crazyfoldername/storage.sdb file. In practice, the sync process gets locked up every time:

Screenshot-PIM Synchronization - KitchenSync-1

Why must you tease me?

Well, I’ve tried everything that I can think of to get my phone to synchronize with any Mozilla product. I’m very close to giving up, which is a shame, because they really are superior products. The ridiculousness of the entire thing is that I can easily dump my PIM data to a folder, and Thunderbird stores it’s data in an SQLite database. If this were Windows, I’d have written a VB app to fix my problems hours ago… Anybody know any python?

Update: I’ve also managed to successfully synchronize my phone with the Evolution mail client. Unfortunately, Evolution looks rather pale next to Thunderbird. In fact, the entire reason that I switched to Thunderbird about a week ago is that Evolution mysteriously stopped receiving my IMAP email with no explanation. No new email comes in, and the Send/Receive button is grayed out. Until now, I was happy with my decision, as Thunderbird is a superior application.

Barry: The Open-Sourced Blackberry Utility

September 30th, 2009 No comments

There is no denying that the installation process for the Barry project sucks. That said, the promise of having the ability to sync my blackberry with a linux-based calendar application like Mozilla’s Thunderbird or the Evolution mail client kept me working at it through the wee hours of the night. The Barry site at Sourceforge provides not one, not two, but four Debian packages (which rely on an additional two undocumented packages), that need to be downloaded and installed in a specific and undocumented order:

  1. libbarry0_0.15-0_i386.deb (sourceforge)
  2. barry-util_0.15-0_i386.deb (sourceforge)
  3. libglademm-2.4-1c2a (debian.org)
  4. barrybackup-gui_0.15-0_i386.deb (sourceforge)
  5. libopensync0 (debian.org)
  6. opensync-plugin-barry_0.15-0_i386.deb (sourceforge)

With the packages installed, I launched a terminal and used the auto-complete feature to find the command barrybackup. At first, I couldn’t figure out what it’s syntax was, until I realized that it doesn’t need any arguments, because it simply launches a GUI (that doesn’t appear anywhere in my Applications menu) that lets you back up your device databases:

Screenshot-Barry Backup

Well, thats a handy utility, assuming that it is also capable of restoring the backups to the device. I shied away from trying the restore feature, as I didn’t have access to a Windows box with which to fix the device should the worst happen.

I’m currently using Mozilla’s Thunderbird (re-branded in Debian as Icedove) as my primary mail client, along with the Lightning calendar plugin, and would be thrilled if I could synchronize it with my Blackberry. You’ll note that libopensync and a Barry opensync plugin were both a part of the installation process; having never used libopensync, I had a tough time figuring out how to make them cooperate.

The opensync page on Wikipedia lead me to install the multisync-tools package, which claims to be able to “synchronize calendars, address books and other PIM data between programs on your computer and other computers, mobile devices, PDAs or cell phones. It relies on the OpenSync  framework to do the actual synchronisation.” I have PIM data that I would like to sync! I have the OpenSync framework! We’re on a roll!

Finally, I installed the multisync-0.90 GUI and opensync-plugin-evolution v0.22-2 opensync plugin packages, which should have allowed me to sync between the Evolution mail client and my phone. I chose to try the process with this software first, as a plugin for Thunderbird was not immediately available. Unfortunately, when attempting to sync, I got this message:

Surprisingly, it was the evolution plugin that failed to connect

Surprisingly, it was the evolution plugin that failed to connect

Useful? Sort of. The Add button let me set up a Blackberry profile with both the barry and evolution plugins, but no matter how I tweaked the settings, I couldn’t get the evolution plugin to connect to my PIM data. Further, after making a synchronization group and adding plugins to it, I couldn’t find a way of replacing a plugin with a different one.

Sick of the limited GUI, I moved on to try KitchenSync, the KDE-based alternative. While it was uglier, I found it to be a far more useful front-end, and managed to get it to sync my device calendar and contacts with my filesystem:

Screenshot-PIM Synchronization - KitchenSync

This process exported all of the calendar and contact information from my Blackberry to a folder full of vCalendar and vContact files on my machine. Now if only I could get Thunderbird to read these files.

After a bit more looking around on the OpenSync webpage, I found a link to these guys, who claim to have programmed an opensync plugin called libopensync-plugin-mozilla-0.1.6 that allows Thunderbird and Lightning to talk to the OpenSync manager. They provide the plugin as a tarball that contains a *.so binary file and a sample *.xml configuration file… but no instructions on how to install them.

Thouroughly lost, I turned to the #opensync channel on freenode.net for help. Until they see fit to help me out, I’m taking a break from this. No sense in giving myself a heart attack out of extreme frustration.

Edit: I got some help from the members of the #opensync channel, who recommended that I drop the mozilla-sync.so file into the /usr/lib/opensync/plugins/ directory. While this didn’t immediately allow OpenSync to see the plugin, I noticed that every other plugin in the directory has an associated *.la configuration file. So I fabricated my own *.la file, and tried again. That didn’t work either.

The members of the channel then recommended that I try downloading the source code directly from the creators. I did as much, and found that it didn’t include a configure or make script, but just the source code. Not knowing how to proceed, I attempted to follow these instructions, which entailed downloading another 20 or so packages, including the sunbird-xpcom-devel package, which again lacks documentation on how to proceed with installation.

Lacking that package, and again frustrated beyond belief, I decided to drop the issue for another hour or so and do some math homework. That’s right, I chose to do math homework over playing with my computer, because this process has been that frustrating.

It doesn’t help that this entire process seems to be aimed at installed BlueZync, and not the opensync-mozilla-plugin. What the hell is going on here?

The Magic of Lenny Backports

September 28th, 2009 No comments

This afternoon saw me in a really annoying situation. I was in a coffee shop, wearing a beret, and writing poetry, and couldn’t get a ‘net connection. The coffee shop runs an open network access point, but some asshat in a nearby complex was running a secured access point with the same SSID.

For some reason, my version of the network-manager-gnome package (the older one that shipped with Lenny) could not tell the difference, and I could not get a connection. When I attempted to force a connection, it crashed. Repeatedly.

This being my first experience with anything on Linux crashing, I immediately (and rashly) determined that the problem must lie with my (relatively) old network manager. After all, I was running v0.6.6-4 of an application that had since matured to v0.7.7-1! And my companions, who were running the latest version, were connecting no problem! Of course, this also wasn’t the first set of problems that I had encountered with my network manager.

So upon returning to my domicile (I’ve always wanted to use that word in a sentence), I hit the #debian IRC channel and asked about upgrading to the testing repository, where all of the latest and greatest code is awaiting release as Squeeze, the next version of Debian. Having heard that the code was frozen in July, and that the release was slated for early spring, I figured that by this point, the code there would be fairly mature, and easy enough to use. To the contrary, the members of the channel weren’t comfortable giving me advice on how to upgrade, since in their words, I shouldn’t be considering upgrading to testing unless I understood how to do as much.

With this warning, I was then given instructions on how to update (which didn’t make me feel any better – the last step in the instructions was “be ready for problems”), along with the suggestion that I check out backports.org first.

Essentially, this site is an alternate repository dedicated to backporting the latest and greatest code from testing to the last stable version of Debian. This means that, with a simple modification to my etc/apt/sources.list file, I could selectively upgrade the packages on my machine to newer versions.

In fact, I had actually already added this repository to my sources.list file, back when I was working on getting Flash 10 installed. At the time, I just didn’t know enough to understand what it was, or what it’s implications were.

So now, running the newest version of network-manager-gnome, a somewhat more recent version of gnome-do, and clinging to the promise that I can upgrade anything else that seems to have gotten better since the time of the dinosaurs when Lenny was released; my urge to upgrade has subsided, and my commitment to wait out the proper release has been restored.

DNS Not Satisfactory

September 25th, 2009 No comments

While trying to connect to a remote webserver via SSH last night, I found that my machine refused to resolve the hostname to an IP address. I couldn’t ping the server either, but could view a webpage hosted on it. Now this was a new one on me – I figured that my machine was caching a bad DNS record for the webserver, and couldn’t connect because the server’s IP had since changed. That didn’t really explain why I was able to access the server from a webbrowser, but I ran with it. So how do you refresh your DNS cache in Linux? It’s easy to do in Windows, but the Goog and the Bing let me down spectacularly on this issue.

This morning, I tried to connect via SSH from my school network, and couldn’t get a connection there either. This reinforced the idea that a local DNS cache might have an outdated record in it, because at school, I was using a different nameserver than at home, and a whole 12 hours had elapsed. Out of theories, and lacking a method to refresh my local DNS cache, I hit the #debian channel on IRC for some guidance. Unlike my last two trips to this channel, I got help from a number of people within minutes (must be a timezone thing), and found out that unless I manually installed one, Debian does not maintain a DNS cache. Well, there goes that idea.

So where was I getting my DNS lookup service? A quick look at my /etc/resolv.conf file showed that the only entry in it was 192.168.1.1, which is the IP of my home router. The file also has a huge warning banner that claims that any changes will be overwritten by the operating system. Makes sense, as when I connect to a new network, I presumably get DNS resolution from their router, which may have a different IP address than mine. The guys on IRC instructed me to try to connect to the server with it’s IP address instead of it’s hostname, thereby taking the DNS resolution at the router out of the picture. This worked just fine.

They then instructed me to add a line to the file with the IP address of the nameserver that the router is using. In the case of our home network, we use OpenDNS, a local company with static servers. I did so, and could immediately resolve the IP of my remote server, and obtain an SSH connection to it.

Well fine, my problem is solved by bypassing DNS resolution at the router, but it still doesn’t explain what’s going on here. Why, if DNS resolution was failing at the router level (presumably because the router maintains some kind of DNS cache), did it work for my webbrowser, but not the for ssh, scp, or ping commands? Don’t they all resolve nameservers in the same way? Further, if it was the router cache that had a bad record in it, why did the problem also manifest itself at school, where the router is taken entirely out of the picture?

Further, will the file actually be overwritten by the OS the next time I connect to a different wireless network? If so, will my manual entry be erased, and will the problem return? Time will tell. Something smells fishy here, and it all points to the fact that my machine is in fact retaining a local DNS cache. How else can I explain away the problem manifesting itself on the school network? Further, even if I do have a local cache that is corrupted or contains a bad record, why did Iceweasel bypass it and resolve the address of the webserver at the router level (thereby allowing it to connect, even though the ssh, scp, and ping commands could not)?

LINUX!!11

Mounting an NTFS-formatted External Drive

September 20th, 2009 7 comments

I have a Western Digital 250GB NTFS-formatted external hard drive that I use primarily to store backups of my Windows machine. Since I’m away from my house for a couple of days, I used the drive to bring along some entertainment, but encountered some troubles getting Debian Lenny to play nice with it:

mount-errorAfter searching around for a bit, I found a helpful thread on the Ubuntu forums that explained that this problem could be caused by a few different things. First, with the drive plugged in, I ran

sudo fdisk -l

from the terminal, which brought up a summary of all disks currently recognized by the machine:

jon@debtop:/$ sudo fdisk -l
Disk /dev/sda: 40.0 GB, 40007761920 bytes
255 heads, 63 sectors/track, 4864 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xcccdcccd
 Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          31      248976   83  Linux
/dev/sda2              32        4864    38821072+  83  Linux

Disk /dev/dm-0: 39.7 GB, 39751725568 bytes
255 heads, 63 sectors/track, 4832 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/dm-0 doesn't contain a valid partition table
Disk /dev/dm-1: 38.0 GB, 38067503104 bytes
255 heads, 63 sectors/track, 4628 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/dm-1 doesn't contain a valid partition table
Disk /dev/dm-2: 1681 MB, 1681915904 bytes
255 heads, 63 sectors/track, 204 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Disk /dev/dm-2 doesn't contain a valid partition table
Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x5b6ac646

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       30401   244196001    7  HPFS/NTFS

Judging by the size of the drives, I figured out that the OS saw my drive at the location /dev/sdb, and the partition that I wanted to mount (the only partition on the drive) at the location /dev/sdb1.

Now, to determine why Linux wasn’t mounting the drive, I checked the fstab file at /etc/fstab to see if there was some other entry for sdb that was preventing it from mounting correctly:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/debtop-root /               ext3    errors=remount-ro 0       1
/dev/sda1       /boot           ext2    defaults        0       2
/dev/mapper/debtop-swap_1 none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto  0       0

Since there was no entry there that should have overwritten sdb, I gave up on that line of inquiry, and decided to try manually mounting the drive. I know that Debian can read ntfs drives using the -t ntfs argument for the mount command, so I navigated over to the /media/ directory and created a folder to mount the drive in:

jon@debtop:/$ cd /media/
jon@debtop:/media$ sudo mkdir WesternDigital
jon@debtop:/media$ ls
cdrom  cdrom0  floppy  floppy0  WesternDigital
jon@debtop:/media$ sudo mount -t ntfs /dev/sdb1 /media/WesternDigital/
jon@debtop:/media$ sudo -s
root@debtop:/media# cd WesternDigital
root@debtop:/media/WesternDigital# ls
KeePass.kdbx  nws  $RECYCLE.BIN  System Volume Information  workspace.tc

As you can see, the contents of my external drive were now accessible in the location where they ought to have been if Debian had correctly mounted the drive when it was plugged in. The only caveat to the process is that the mount function is available only to root users, meaning that the mountpoint was created by root, and my user account lacks the necessary permissions to read or write to the external drive:

no-permissions

I figured that this issue could be solved by using chmod to grant all users read and write permissions to the mountpoint:

root@debtop:/media# chmod +rw WesternDigital
chmod: changing permissions of `WesternDigital': Read-only file system

Well what the hell does that mean? According to this post (again on the Ubuntu forums), the ntfs support in Linux is experimental, and as such, all ntfs drives are mounted as read only. Specifically, this drive is owned by the root user, and has only read and execute permisions, but lacks write permissions.

According to this thread on the slax.org forums, there is another ntfs driver for Linux called ntfs-3g that will allow me full access to my ntfs-formatted drive. After sucessfully adding the ntfs-3g drivers to my system, I dismounted the drive, and attempted to re-mount it with the following command:

mount -t ntfs-3g /dev/sdb1 /media/WesternDigital

This time, the mount command appeared to almost work, but I got an error message along the way, indicating that the drive had not been properly dismounted the last time it was used on Windows, and giving me the option to force the mount:

Mount is denied because NTFS is marked to be in use. Choose one action:

Choice 1: If you have Windows then disconnect the external devices by
 clicking on the 'Safely Remove Hardware' icon in the Windows
 taskbar then shutdown Windows cleanly.

Choice 2: If you don't have Windows then you can use the 'force' option for
 your own responsibility. For example type on the command line:

 mount -t ntfs-3g /dev/sdb1 /media/WesternDigital -o force

Well, since I didn”t have a Windows box lying about that I can use to dismount the drive properly, I’ll took a shot at using the force option. After warning me again that it was resetting the log file and forcing the mount, the machine finally mounted my drive with full permissions for the owner, group, and other users!

drwxrwxrwx 1 root root  4096 2009-09-18 15:40 WesternDigital

After a couple of manual tests, I confirmed that both my user account and the root user had full read/write/execute access to this drive, and that I could use it like any other drive that the system has access to. Further, thanks to the painful XBMC install process, I already had the codecs required to play all of the TV shows that I brought along.

Wireless Network Manager Woes

September 16th, 2009 No comments

Debian Lenny ships with the Network Manager package, version 0.6.6-4, which for all intents and purposes is a well written and very useful network management application. But of course, I wanted something more. At home, I have my music library (hosted on a Windows Vista machine) shared to the local network, and wanted to mount that drive using Samba so that I could share my music library between my two machines while on my home network.

On a Windows machine, one can just point an application to files on a networked drive, while Windows handles all of the dirty details related to allowing that application use those files as if they were on the local machine. On Linux, the application in question seems to have to be aware of how to handle a Windows share (usually via the Samba package), and handle that drive sharing on it’s own, unless the network drive has been mounted first. Further, when mounting a network share in Linux, one can choose any folder on their hard drive to put its contents into, ensuring that it always appears in the same location, and is easy to find.

Unfortunately, as far as I can divine, a networked drive can only be mounted by the root user, which seriously reduces the number of applications that can perform that mounting action. In my quest to get my home music share working, I looked into plenty of different methods for automatically mounting network drives, including startup scripts, modifying the fstab file, and manually connecting from a root terminal. None worked very well.

Eventually, I stumbled across a web post advertising the pros of the WICD network manager, which as I understand, will be used as an alternative to the network manager package by Debian Squeeze, and can currently be pulled into Lenny by adding the Debian-Lenny Backports repository to your sources list. I installed it, replacing the default network-manager-gnome package.

My first impression of WICD was extremely positive. Not only did it connect to my home network immediately, it also allowed me to define default networks to connect to (something that is conspiciously absent from the NetworkManager interface), and to set scripts that are run when my client connects to or disconnects from any of the networks in the list. This allowed me to write a simple one line script that mounted my network share on connection to my home wireless network. It worked every time, and mysteriously did so without asking me for my Sudo password, even though it used the sudo command internally to get rights to perform the mount.

Odd security peculiarities aside, I was happy with what I had accomplished – now I could tell my laptop to automatically connect to my home wireless network, and to mount my music share as soon as it did so! Then I went to school. Shit.

The wireless network at my University uses EAP-TTLS with PAP inner-authentication as a security protocol, something that WICD apparently had no idea how to handle. This protocol is extremely secure, as the host identifies itself to the client with a certificate that the client uses to tunnel into the host, allowing connection to take place without any user information being passed in the clear. At least that’s how it’s supposed to work, except that our school doesn’t have a certificate or certificate authority, so… Whatever.

In any case, WICD does not include a template for this type of network (which is fair I suppose, since Windows requires an add-on to access it as well), but for the life of me, I couldn’t figure out what to do to fix the problem. I trolled the internet from a wired machine and tried editing the WICD encryption templates, while Tyler (on Fedora) and Phil (on OpenSuse) connected on first try.

Eventually, after an hour or so of fruitless trial and error, I gave up, came home, and reinstalled the NetworkManager application, because that’s what Tyler and Phil were using on their systems, and it seemed to work fine. Sure enough, the next day I connected after just a minor tweaking of the network properties in the NetworkManager dialog.

Unfortunately, while I can now connect to my home and school networks, I once again have lost the ability to automatically connect to networks, and to execute scripts on connection, meaning that I’m back to square one with the mounted networked music share – for now, I just do the mounting manually from a root terminal. Balls.