We mirror the Webmin website to bring it somewhat closer to Sweden, and recently I had to move the hosted mirror to another of our servers running Debian 8. All of a sudden, a cron job that had been working for many years went tits up with a segmentation fault.
Odd, to say the least. It became even more strange when I turned on “verbose” (-v) output and wget told me that “UTF8 cannot be converted to UTF8”. This is a truly silly error message, imho. wget apparently knows the local encoding, and it apparently knows the remote encoding, so why is it attempting a conversion when there’s non conversion needed?#stupid
Adding –no-iri to the wget command-line solves this issue.
If you, like me, are using Ubuntu – or similar – for your daily stuff and need to connect to a Windows Server by using RemoteDesktop (RDP) / TerminalServer, you may find that local (Linux) resources are not made available to you on the Windows side.
The Remmina client on at least Ubuntu 14.04.LTS is very outdated. Go grab the latest version directly from their site. Installs without issues and gives you a “somewhat” more up-to-date RemoteDesktop Client for Ubuntu Linux.
sudo apt-add-repository ppa:remmina-ppa-team/remmina-next
sudo apt-get update
sudo apt-get install libfreerdp-plugins-standard remmina remmina-plugin-rdp
#remmina #linux #rdp #remotedesktop
All of a sudden, rsyslogd on an Ubuntu installation running under OpenVZ is using 100% CPU. One alternative is to replace rsyslogd for syslog-ng, but if you want to “fix” rsyslogd instead, here’s how:
service rsyslog stop
sed -i -e 's/^$ModLoad imklog/#$ModLoad imklog/g' /etc/rsyslog.conf
service rsyslog start
Quite some time ago, we needed to move a customer’s MySQL 4 server from one location to another. In the process, we figured we’d update the server to use some moderately modern version like MySQL 5.0 at least. Also, if we were to have any chance of virtualizing and upgrading the actual server environment to something more modern like Ubuntu 10.04.LTS or 12.04.LTS, or Debian 6.0, we’d have to re-compile the sources regardless. Not taking other incompatibilities into account, that line of thinking ran into Chuck Norris because the Windows DLLs supplied with the application using the database were not compatible with anything but MySQL 4.
The particular version of MySQL 4 running on the customer’s server was self-compiled (by us), so I figured I’d at least locate the “most recent” version of MySQL 4. To my surprise, this turned out to be harder than I could possibly imagine. In a world where “nobody” forgets anything, I could not find a single trace of a source distribution for MySQL 4. Google, Facebook, Microsoft, and Apple probably know the size of shoes I wear, but they don’t know where MySQL 4 sources are located. This struck me as very odd as MySQL 4 was a) very popular, b) open source, and c) should at least reside on half a dozen servers on the Internet, or so I thought.
Like a core dump out of the blue skies, someone Skyped me a link today. The person had ran into a mirror archive and remembered that I was looking for this “eons ago”. I have now mirrored most of that archive into/onto my own cloud store. I’ll go through that in a few days and remove the things I don’t need, but this may very well turn out to he a lifesaver.
I wonder if Sun and/or Oracle decided that keeping old MySQL versions around was a bad idea …
If you, like me, need to find some odd version of MySQL, for whatever reason, here are two links that may be of good use to you: