Xerox Phaser 3052 against Debian Linux – shell wins, admin loses

Installing a printer in Linux should not be a challenge nowadays… It shouldn’t, should it? Shoot it, it shouldn’t.

I have this wonderful Xerox Phaser 3052 that works beautifully and I had to get it working with my new Linux notebook. I vaguely remembered that when I was installing it for my old notebook the procedure was not very despicable, so I was full of high hopes and thought I would be printing away in a few minutes. It works for the old one, right? Well, whaddayaknow, two days later I have a simple install procedure that works and a desire to strangle a few Xerox and Debian developers.

The necessary filters and all that (driver package) are available at Xerox Driver download for Phaser 3052 and that is wonderful. Simply download that and then load also the Debian package for the Phaser 3010-3040 driver.

Unpack the second one and marvel at the i386 architecture .deb package. Now, of course, we are running a 64 bit architecture, so we will have to add the i386 to be able to use that. Fortunately, that is simple:

dpkg --add-architecture i386
apt-get update
apt-get install libcups2:i386
apt-get install ./xerox-phaser-3010-3040_1.0-28_i386.deb

It should all work like a charm. Now we have to install the filters. Unpack the first package and change into the “uld” directory. If you now try to run install-printer.sh, you will be not surprised that it doesn’t work.

# ./install-printer.sh 
**** Running install ...
**** Press 'Enter' to continue or 'q' and then 'Enter' to quit. : 
./noarch/package_install.sh: 57: local: 3052/uld/noarch/.version-printer: bad variable name
**** Install finished.

Spending a long evening trying to figure out what is wrong with the script did not help. Fortunately, in the morning I was a little brighter and suddenly decided to check what shell the scripts are running with. And, damn, it isn’t bash.

# l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 24  2017 /bin/sh -> dash*

There is a little what’s it in the fact that all scripts are written for bash and the Debian developers decided that switching to dash would be a bright idea. No, really? Ok, now the fix is obvious and simple:

# cd /bin/
# rm sh
# ln -s bash sh

And suddenly, like if by magic, it all works…

# ./install-printer.sh 
**** Running install ...
**** Press 'Enter' to continue or 'q' and then 'Enter' to quit. : 
**** Are you going to use network
--> continue reading →

Debian 8 to Debian 9 “stretch”

Debian 9 “stretch” turned out to be a stretch indeed. A stretch of my patience and imagination it is. I finally got around to upgrading my desktop and servers to the latest stable and I am not amused. Oh, being on Debian for nearly 20 years I did plenty of upgrades and none of them were painless. Most of the time I actually ended up scrapping the system and installing fresh copies of servers to make sure things work. Recently it was getting better though and I did not see too many angry shouts about the upgrade so I decided to give it a go. I marked up this weekend for the upgrade because experience taught me I was going to need time to fix things before the work starts on Monday.

Well, all right, so on the desktop many applications were simply uninstalled. Fine, when I need something and I notice it missing I install the tool again. That’s annoying but no big deal really. The upgrade itself failed, predictably, but with a little push from our friend ‘apt-get install -f’ the upgrade worked its way through and actually completed, which was a pleasant surprise overall. On the servers though things are not looking good at all.

The update went fairly quickly and without errors so I was amazed with the smooth action. I did feel a little suspicious but after reading through the apt-listchanges did not see anything Earth shattering and felt reassured. Little did I know of what the next hours would bring… The mail server went quietly away and would not start giving me weird errors. I was certain I read about postfix updates in the apt-listchanges but this did not look like anything described there.

After a while I realized that I am looking at some strange errors and configuration of MariaDB instead of the MySQL. Oh, my! That was not mentioned anywhere during the upgrade, was it? No, really! Debian has quietly yanked the MySQL out of my server and installed MariaDB instead. Moreover, it pretended to port my DB to MariaDB, meaning they were now not compatible with MySQL!

Fantastic. So I headed to the MySQL sites where folks of Oracle actually give a fair warning that, yes, Debian will silently replace the database on upgrade. And Debian did not mention it except to note triumphantly that they provide now a much better and transparently compatible database in a press release.

Well, I tell you what. The MariaDB is not transparently compatible. It breaks … -->

continue reading →

Rotating videos with ffmpeg

Often, a video taken with a mobile phone will be rotated in a different way than you expect. It may be taken vertically or upside-down. So you may want to correct that and get yourself a properly rotated video for viewing on computer.

All right, on Linux we use ffmpeg and there is no problem with it. The ffmpeg will happily rotate the video. What you do not expect is that the rotation information will remain in the media and then the player will try to rotate it again. What you get is a mess and you will be cursing away trying to understand why your video ends up upside down all the time although you enter the parameters to rotate it correctly.

So, the first thing you want to do is to remove the meta-information about rotation from the video. Like this:

ffmpeg -i 20160225_211430.mp4 -metadata:s:v rotate="0" -codec copy 20160225_211430_2.mp4

Once the meta-information is gone, we can check the actual rotation of the video stream and finally correct it with the ffmpeg:

ffmpeg -i 20160225_211430_2.mp4 -vf "transpose=1" 20160225_211430_3.mp4

Interestingly, the meta-information is used by some players and not used by others, so the results are unpredictable if you leave the video rotated. I prefer it to be “physically” rotated to the right direction and remove the original rotation angle – then you get reliable view on all devices. More or less :)… -->

continue reading →

Containers gone wrong: lxc vs. xen

I run a few websites myself and I was always keen on making my life easier looking after them. So virtual servers and services are not something that I ignore if you catch my drift. I have been running xen for quite a long while and I have to say it is bothersome to upgrade all of those linux machines running this and that, isn’t it?

So I did try some other virtualization approaches before and I quite liked the idea of the OS level virtualization, that is similar to the regular BSD jails, but on linux and it worked nicely.The virtual machine was not that well isolated, I was a bit cautious to use it in production but the idea stuck – mainly because of the ease of maintaining the server, where you upgrade the OS only once and all VMs get the updates automatically, since they simply run from the root FS of the main machine, basically.

So when people started to come across with the lxc and docker, calling them “mature” and “OS level virtual machines”, I was rather excited to try them on. I thought they would provide the same idea – secure virtualization of the running processes environment while keeping the FS in sync with the main host, allowing for an easy maintenance.

Oh, boy, was I into a major disappointment! First, the whole thing of lxc is based on downloading virtual machines over the Internet from an insecure repository. Okay, we do that with Debian, but Debian has been around for many a decade, so we kinda trust them, all right? Why should I want to run my production services on a VM that has been installed by someone else and offered for me as a download? What a silly idea indeed.

But, secondly, it is no better than hardware-emulating hypervisor-based virtualization in terms of maintenance. Once you get this VM downloaded and installed, it behaves completely separately. You have to go to each VM and update it manually! Except that you share the kernel and you may have a compatibility problem there, oops. What sort of nonsense is that? Why would anyone want to move from xen to lxc if the maintenance is the same but security and quality is down the drain, eh? For some mythical changes in performance or what else?

So, to summarize: I say lxc and everything based on top of it sucks. It serves no real purpose, it is an over-complicated exercise in engineering that solves a non-existing problem (if any at all).

What we really need is something similar… -->

continue reading →

Getting email off your Linux server with ssmtp and yandex

A quick note to self about configuration of servers with ssmtp and yandex mail service (any other would work too, of course). I keep forgetting how it is done and keep spending time looking about so here goes the summary.

Install ssmtp package, if missing, install also bsd-mailx.

Configuration for ssmtp goes into /etc/ssmtp/ssmtp.conf

MailHub=smtp.yandex.ru:587 # Provider SMTP server hostname and port
UseStartTLS=YES # Secure connection (SSL/TLS)
FromLineOverride=YES # Force the From: line
Hostname=example.com # The name of this host
RewriteDomain=example.com # The host the mail appears to be coming from
Root=webmaster@example.com # Redirect mail for root@ to webmaster@example.com
AuthUser=webmaster@example.com # Provider mail account
AuthPass=password # The password for the mail account

Note that it is not UseTLS anymore but UseStartTLS, otherwise you’ll get

May 25 18:47:18 example sSMTP[315]: Creating SSL connection to host
May 25 18:47:18 example sSMTP[315]: SSL connection using (null)
May 25 18:47:18 example sSMTP[315]: Cannot open smtp.yandex.ru:587

Now all of the accounts that send email must be mentioned in the /etc/ssmtp/revaliases file and be mapped to this existing account at the provider:

root:webmaster@example.com:smtp.yandex.ru
www-data:webmaster@example.com:smtp.yandex.ru
cron:webmaster@example.com:smtp.yandex.ru

Now we have a working configuration but the password for the service is exposed in a world-readable config file. To fix that, we create a new group:

groupadd ssmtp

Change the ownership of both the config file and the sSMTP binary to this group:

chown :ssmtp /etc/ssmtp/ssmtp.conf

chown :ssmtp /usr/sbin/ssmtp

Set the SGID bit for the binary so that others invoking it get the proper permissions:

chmod g+s /usr/sbin/ssmtp

And restrict the permissions of the config file:

chmod 640 /etc/ssmtp/ssmtp.conf

Now everything should work like a charm… unless I forgot something again :)… -->

continue reading →

Moving email from one IMAP server to another

Ah, the power of tools! What do you do when you want to move lots and lots of email between two IMAP servers? Sure, you could open them both in Thunderbird and drag-and-drop messages. It would simply take forever and you would be transmitting messages first to your computer and then back to another server. And Thunderbird has a bad habit of timing out. There is a better way.

Login to the server (or you can do it actually from client if transferring back and force is okay). Get mutt. Then open the source mailbox like this:

mutt -f imaps://albert%40example.com@imap.gmail.com/%5BGmail%5D/All%20Mail

and wait for mutt to load the headers of the email. Once it is ready, select all messages by pressing T and entering ~A. Save the messages to your target server by pressing ;s (if you want to move the mail) or ;C (if you want a copy) and giving the destination IMAP server:

imaps://albert%40example.com@mail.example.com/INBOX

And watch the magic of UNIX tools unfold :)… -->

continue reading →

Ubuntu on X201i

Finally, I got the Ubuntu graphics properly work on my Lenovo X201i. It took quite a while and the problem was the graphics card. It would give me blank screen at start-up during the installation, so I gave the kernel the “i915.modeset=0” option according to the advice found after some searching high and low. It worked.

The problem is that it doe snot really quite work… First, the graphics mode is weird, it does not use the accelerator, it seems, so you can’t have the bells and whistles of the interface. That I could live with. The other problem was more serious, the screen would not come back from blank when going to the sleep mode (close the lid).

That second problem was sort of fixed with the option “SAVE_VIDEO_PCI_STATE=true” given to the ACPI (/etc/default/acpi-support). Unfortunately, this never worked reliably and sometimes the computer would freeze on suspend or on resume. Finally, that got me fed up.… -->

continue reading →