Author: Jani

  • Solved: svn: Working copy 'wp-content/themes/default' is missing or not locked

    I ran into this problem when trying to upgrade several of my WordPress-powered blogs through Subversion. The cause was that I had replaced the default theme directory with a copy of my working theme, due to the ‘reverts to default’ bug which, by the look of things at WP’s support forum as well as my own experience, is still alive and well.

    The default theme is part of the svn repository and svn expects to find its own data on the current status of the files, but a copy of my own theme doesn’t have the data, so it complains about the missing or not locked working copy. The solution is to delete the default theme directory based on my own, then do a svn up to fetch a copy of the original default, then do a copying-over: cp -r my-working-theme/* default/

    Now the working copy of the default looks like my own, yet is seen by svn so that a svn sw http://svn.automattic.com/wordpress/tags/2.3.3/ (or whatever the new version is) is possible. Note that editing style.css is required to tell the default apart from the actual working theme. I also like to use the screenshot of the original default to make it stand out when the working theme once again gets replaced by the default.

  • WordPress 2.3.3 Released

    WordPress 2.3.3 is an urgent security release. A flaw was found in our XML-RPC implementation such that a specially crafted request would allow any valid user to edit posts of any other user on that blog. In addition to fixing this security flaw, 2.3.3 fixes a few minor bugs.

    WP Dev Blog

  • Ubuntu: setting up SSHFS for elegant SFTP

    I needed to edit data on my webserver, and initially, still thinking in Windows terms I considered installing gFTP. But then I realized that networking is much more integrated in UNIX, and a separate application is not necessary: mounting my server directory was as simple as choosing to do so with Nautilus’ File > Connect to server item and providing the credentials.

    But there’s an even more elegant way of doing things. SSHFS integrates remote locations into your system seamlessly, allowing you to use them as if they were genuine directories under your local file system.

    For Gutsy Gibbon, all I needed to do to get the basic SSHFS functionality going was to install the sshfs package. But then I went ahead and integrated my home directory on the web server so that it’s now mounted automatically at boot. For this I adapted a set of instructions provided over at Debian/Ubuntu Tips & Tricks, as well as ones given in an Ubuntuforums thread.

    First, I created the local mount point for the remote location, and gave myself permission to modify it:

    sudo mkdir /media/my-remote-login
    sudo chown root:fuse /media/my-remote-login
    sudo chmod g+w /media/my-remote-login
    sudo adduser my-login fuse

    Then I added the mount point to /etc/fstab, adapting Darwin Award Winner‘s instructions to my own liking, with the following line (note that it all goes on a single line, the line breaks inserted below are only due to limited column width):

    sshfs#my-remote-login@my-web-server:path-to-my-remote-home-directory /media/my-remote-login fuse users,uid=my-local-uid,gid=my-local-gid,reconnect,transform_symlinks,BatchMode=yes 0 0

    (You’ll find out your local uid and gid with id.)

    After this, I had to do a sudo - my-login to activate the changes made to group settings (the adding of my-login into fuse), before the remote home was mountable (mount /media/my-remote-login) with my normal user account. (Otherwise the changes won’t be in effect until the next log-out and log-in.)

    Then I adapted prankst3r‘s instructions for establishing trust between my local host and the remote server:

    cd ~
    ssh-keygen -t rsa

    I left all the fields, including the passphrase, blank (just pressed enter).

    cd .ssh
    sftp my-remote-login@my-web-server:path-to-my-remote-home-directory/.ssh
    put id_rsa.pub
    quit
    ssh my-remote-login@my-web-server
    cd path-to-my-remote-home-directory/.ssh
    cat id_rsa.pub >> authorized_keys
    chmod 600 authorized_keys
    logout

    After this I was able to log in to the server (ssh my-remote-login@my-web-server) without having to type in the password, and after the next boot, my remote home was fully accessible (with read/write/execute permissions) from /media/my-remote-login with the command-line as well as Nautilus.

  • Solved: Nautilus: 'Show hidden files' in folder view not remembered

    I had set Nautilus to show hidden files by default, yet wanted to deviate from it with my home directory. But each time I re-opened it with Nautilus, the hidden files were shown, so it seemed there was no per-folder memory when it came to this option.

    I found an interview which mentioned Show hidden files is a per-window setting and has been stored per-folder since Nautilus 2.8 – but the key here is that it only does so in what is called the spatial mode. And Ubuntu, by default, comes with Nautilus set to the browser mode.

    After catching up on this issue by reading The Spatial Way by Colin Charles, I became a believer and decided to go with the spatial mode. The Gconf key which toggles between the two modes is /apps/nautilus/preferences/always_use_browser. After unsetting it, Nautilus now remembers I want to see my home folder without the hidden files by default. Yay!

  • Ubuntu: USB keyboard not working after powerdown, powerup

    I’m affected by Bug #48773, which, if I understand it correctly, means that my Nforce2 motherboard’s BIOS (the latest, FN45S00W from Shuttle) doesn’t treat the shutdown signal like it should, leaving all USB devices powered on. Windows (XP) isn’t affected or maybe it has a workaround – possibly something similar to the one presented over at Launchpad and Kernel Bug Tracker.

    My setup doesn’t have annoyingly bright lights, but I do have one particularly troublesome issue related to this problem: my USB keyboard doesn’t seem to be able to wake up when I turn the power back on. I have to unplug and replug it in order to resurrect it. There is a weird performace issue in Windows when I hook it up into the PS2 port with an adapter, so I’d rather keep it plugged in as a USB device. But I may have to reconsider, since an official fix for the issue is considered unlikely.

  • Wanted: a simple Gnome reminder application/applet

    For those who are willing to install stuff outside Synaptic there’s Alarm clock (haven’t tried it myself), but for the rest of us it looks like there’s no going round Evolution.

    Thanks to Mr. Murphy, I went looking for a reminder app right after uninstalling Evolution, for which I had no use. Of course, this caused the calendar available from the panel’s clock not to have any such functionality at all, so I had to go back and re-install Evolution. It’s a shame, because although Evolution’s calendar probably does everything you could ever want, it seems like overkill for someone used to the rather minimal Freebie Notes from Power Soft in Windows.

  • Solved: Ekiga (Ubuntu): Registration Failed: Forbidden (Rekisteröityminen epäonnistui: Estetty)

    It looks like they’ve really screwed up the account management over at Ekiga.net: I was allowed to create an ID with a password using special characters, but then the Ekiga client failed to log in with it (giving me the error message I titled this entry with) and I couldn’t even log in at the website.

    After requesting my password via e-mail (at the login website) as if I had forgotten it, I got an email not with the password but with a URL which, when clicked, gave me a new password. The new one was a measely five characters long; is that how insecure they expect them to be? Well I changed it to yet another one, still 20 characters long but this time containing only numbers and letters, and it seems to have solved the issue: I’m now able to login with the client.

  • Solved: Ubuntu: cannot save KeePassX database / saving disabled

    This is probably the dumbest user error made in the history of computing, and thus probably useful only if you want to have a laugh at my expense. Go ahead, I fully deserve it.

    I had successfully switched my Windows storage drive to NTFS-3G and thought I would now have write-access to KeePassX‘s database. But despite having write-access to other files (such as images) on the drive, the Save button was still disabled in KeepAssX after opening the database file from it.

    I tried copying the database to my home directory and opening it from there, but it remained unsavable. I checked, and all the access bytes were as they should be in order to allow for modifying the file. I tried creating a new database, and that seemed to work. I even contemplated exporting the old database to another format in Windows and then importing it in Ubuntu…

    …until I realized I hadn’t actually made any changes in the database prior to trying to save it.

    That’s right. After creating a test entry into the database I could save it just fine, even onto my NTFS drive. Doh!

    I fully understand the reasoning behind disabling the saving function when no changes have been made in the data (KeepAssX is hardly alone in this choice of logic), but in this case my intuition seemed to work massively against that logic, so I guess that qualifies the issue as one of accessibility.

    In my defence I can say that I did change the order in which the entries are shown in KeePassX (for some reason they seem to default to reverse alphabetical in Ubuntu) before trying to save, and that’s why my subconscious mind fully expected saving to be enabled. Apparently the listing order is not among the data saved in the database, but if it is, the Save button not reacting to it is an obvious bug in KeePassX.