I have been having problems allowing Irfan to upload files to his web root directory in his home directory without having the webserver being forbidden from serving his site. It turns out that it works if I chown -R his directory with irfan:www-data (www-data as set as group in apache2.conf) and chmod -R everything to 755.
The hard drive of BOINC zombie #4 seems shot. It’s making weird ticking noises, and when I rebooted, (after unplugging it) the filesystem was so shot it couldn’t recover from the damage to the point there was no hostname – it showed up as (none) – and I couldn’t even log in. I couldn’t even reboot with ctrl-alt-del! I was figuring I’d reinstall Debian, but given how awful the hard drive sounds I figured it wouldn’t even be worth the effort. Then I realized that since it seemed all the other bits and pieces of the machine seemed to be in working order, I could run it as a live system of a CD! As luck would have it,Â Debian has official live CDs. So now I think I’ll wipe the drive, add it to the pile of drives to be recycled, and start running zombie #4 off a live system. It might not be as snappy, but the entire CD image is only 106MB!
Gfire is an extension for Pidgin that allows for Xfire support. I compiled mine from source, partly because I can, partly because I was too lazy to google for a .deb, and partly because there’s no official Hardy AMD64 .deb availible on the above snapshot page. Here’s what I had to do to compile:
- Download and extract source archive (should be in a directory path without spaces)
- Install pidgin-dev and imagemagick
- From the source directory, run ./configure –prefix=/usr
- Run make
- Run sudo make install
Done! You don’t even have to restart Pidgin, just add another account and it’ll be in the dropdown protocol list!
I’ve only tested this is Hardy Heron at the moment, but it appears that, given the proper repositories, it is now possible to install applications from the browser! It’s not only an idea, it’s in practice! This’ll let tutorials consist at least partially of application installation links! ^^
You know Brasero, the new (and very shiny) CD burning suite in Hardy Heron? I have had two problems with it thus far in the course of burning the RC ISO from my beta installation. My root partition for the beta only had around 550 MB left – not enough to mirror the ISO in a temporary directory. It failed with a vague error message:
Error while burning:
the selected location does not have enough free space to store the disk image (692 MiB needed).
Yes, the error message really was that poorly written. I tried another CD, thinking (incorrectly) that there might be something wrong with the CD itself, but I noticed that Brasero itself reported the CD with 702 MiB or so of space, and recordable. I poked around, and under the properties button next to the drive selection, I found a temporary directory with, you guessed it, around 550 MB free space. I told it to use my other ext3 partition, and it burned the disk happily. It then ejected the disk, then requested I put it back in for a read verify check. I did so, but Nautilus popped up first, showing me the contents of the disk, and there was also a package manager asking since there were packages on the disk if I wanted it to open. I said no. Brasero complained that the drive was in use. So much for read verify. I’ll see if I can post my errors somewhere where they can be addressed. Maybe they’re already fixed in the RC…
EDIT: Yup, it seems to be fixed now. I got a read verify to run.
EDIT2: It helps to disable the automatic display of the contents of new media in Nautilus’ preferences. To disable everything Nautilus does to the disk, you’d probably have to disable it popping anything up when a disk has software on it, too.
The Ubuntu packages for Wine version 0.9.56 were taking a while to reach the repositories so I could upgrade with just two apt-get calls, which is rare. I got impatient, which is not rare, and just compiled my own version.Â I uninstalled the repository’s version with apt-get get, checked running wine to make sure it was uninstalled, and ran a sudo make install after ./configure and make && make depend in the source directory. Easy. The problem was that then wine refused to run, saying it could not be found. I tried running make install after su’ing (changing to root) just out of desperation. It worked! So did sudo wine. That was weird. I tried a sudo whereis wine, and found it to be in /usr/local/bin/wine instead of the /usr/bin/wine that my bash was complaining could not be found. I hopped on the IRC and thought out loud, which I guess was a pretty annoying thing to do, but whatever, it helped. I linked /usr/local/bin/wine to /usr/bin/wine, which fixed the problem. This person in the channel told me I shouldn’t do that, and said that bash just needed to restart. I removed the link, (with the logical unlink) logged off my terminals, then logged back in, and it worked! Yay! Well, now I know what to do if I ever run into something like that again. You learn something every day, huh? 🙂
I recently started trying to set up zoneclient to update my DNS listings if my IP changed. I wanted to have it checked extremely often, yet not waste zoneedit’s bandwidth by checking up with them every 3 to 5 hours via cron. This problem was brought into new light when Irfan tried to pull up my site during Biology class and failed. Tandoc was nice enough to let me check what was wrong after class, (we finished a bit early) and my IP had changed, although I could do nothing to fix it from school.
I was having a problem with zoneedit. Although it claimed to support getting my external IP from my router, for some reason it was checking the wrong page. I have no formal or even really informal experience in Python, and my attempts at poking the code produced nothing helpful. I contacted Kal, the sole maintainer of the code. He replied in close to an hour, which was a pleasant suprise. I explained my problem and gave him my logs, and within 5 hours of email back and forth the problem was completely solved! I now have the script running every 5 minutes. Excessive? Yes.
I’m also writing a C++ fish tank simulation program as qualification for Camp CAEN‘s advanced C++Â Game Development class. We’re supposed to draw a fish tank in text on the screen, then when space is pressed, randomize all the positions of the fish and draw again. Multiple fish in one position are shown as a * instead of their type letter. This program is also supposed to be able to read in the number of fish and tank dimensions from a file at runtime. When I started it had been quite a while since I had done any C++. The initial part went relatively quickly, (drawing the fish tank, having the fish randomize) but I was stumped with the memory errors I was getting when I started easing the thing into being dynamic and read its settings in at runtime. After spending quite a while troubleshooting with the help of those in ##C++ on freenode, I found that my problems were because I was accidentally declaring a local instance of the member variables I was attempting to initialize in my constructor. Whoops. Let’s see if I make that mistake again in a hurry.
EDIT: Alter Ego!
I have two things:
- Guild Wars runs perfectly under Wine, no tweaking.
- VirtualBox is interesting, and much less nerve-wracking then trying a new OS on a real system. I intend to use it to try out new distributions more easily.
Also, logical volume management sounds interesting. I think I’ll check that out later…
I recently ran a virus scan on my Windows partition from Linux. It took six hours and completed overnight. The results were the last thing printed to the terminal. It showed it had scanned some 84 gigabytes of data, and that there were 13 infected files found. As I looked around, I couldn’t find a search function in the terminal, and the scroll bar didn’t even go up far enough. How would I find out which files those were? I ran the scan again, but instead of the clamav -r /media/hd1 of the first time, I used clamav -r /media/hda1 &> clamav.log to dump all the output to file. The scan completed for a second time, and again found 13 infected files. I came to my next problem. How on earth would I find the lines of the infected files out of the 106,064 lines in the log? I tried searching for DETECTED, but that didn’t work. I discovered I should search for FOUND. I wanted to get the lines in a separate file because I could, which was easy with cat clamav.log | grep FOUND &> infected.log. It turned out all of the marked files were part of Warsow, an open source multiplayer FPS. The detected virus was Oversized.Zip. When I googled this, I found that it was because the compression ratio had exceeded some threshold somewhere. The pages often mentioned it in the context of a false positive. I think I just spent 12 hours trawling through my hard drive looking for 13 false positive compressed archives. It was fun, though. I got to use command-line fu. 🙂