Sunday, March 24, 2013

gnome-keyring, LDAP, PAM -- lost weekend blues

Links: LDAP workaround for Slack   CUPS LDAP issues

Today's distro's often install security as if one's stand-alone machine were a network box - localhost looping back onto itself with PAM and LDAP. In an environment like this, if one attempts to directly attach a peripheral, one becomes delayed or entirely thwarted. Anything from an improperly operating keyring to some limitation of root (eg, root apparently cannot navigate an IP localhost inherently), or so forth can extend attaching a printer into weeks. These are not problems for hackers; these are limits upon the computer's owner(s). Why?

I have no f*cking idea. Public agencies already can directly access our systems and private hackers either know how to use these LEA backdoors or have their own software methods. So for our home systems there is perhaps a 1% security gain for having an encrypted-vaulted system that loops back onto itself with layered authentication and cryptography. Meanwhile there is about a 70% productivity loss and about a 140% frustration increase to go along with it. Nearly all savvy computer users below the level of industry professionals or CS majors (they presumably can write patches to solve authentication situations), would pay GOOD money to defang all of their "security" beyond an initial login. As I noted in the previous post, users of Ubuntu (Ubuntu appears to use every layer of loopback LDAP, PAM, SOAP, encryption spaghetti available), are forced to, basically, hack their own systems to accomplish something as simple as directly connecting a printer.

Of course there are "solutions" for us; spend hours on forums and maybe make a post --- one could wait anywhere from one to several days or weeks for a possible workaround. Or one can spend the weeks necessary to resurrect their IPtables knowledge, uninstall LDAP, and parse out how to connect to web services without having LDAP and so on in place (eg try NSS without LDAP!).

This rant isn't against Ubuntu, it's a vent regarding loopback security for stand-alone machines. Leave layered loopback security, which places a security server and client on a single machine, out of vanilla distros. The so-called hackers out there already read our credit card numbers and have a hundred other entry points into our systems through dynamic libraries and so forth than this ridiculous set of authentications can ever prevent. Meanwhile, we end-users struggle to connect peripherals. Iptables and (arguably) a well configured PAM are our stand-alone friends. Loopback localhost security "services" are not.

Saturday, March 23, 2013

cups - hp office jet pro 8500a - 12 hours of fail in Lubuntu

Links: open printing.org   scroll down for tarball link   uninstall hplip   hp-setup options
Note this may also play HEAVILY into encountered problems with Ubuntu/Lubuntu printer addition: gnome keyring fiasco
So a year and a half ago, I added this printer in Minislack/Zenwalk. In 2013, I'm into Lubuntu, mostly for an updated set of libraries for the time being. I know Lubuntu (so far) uses usblp for usb printers so it should go OK. One thing, I'm expecting to compile my core applications as I've already noticed from Ubuntu/Lubuntu versions of avconv and ffmpeg, that they seem to be watered down. I suppose they have to be for such a popular distribution, so I keep my expectations for this distro to having a recent set of libraries for compiling. Back to our printer story... scroll down to Pt 3 for installation.

Pt 1 Groundwork

  • HPLIP has apparently changed to where it must now be compiled to get the .ppd's out of the source? (Edit 2013-03-24 after unpacking the HPLIP source, the .ppd's are available, but in a compressed "gz"format, eg "hp-officejet_pro_8500_a910.ppd". Select and use as needed (chmod 644 the file) without proceeding further with HPLIP compilation. Save both "hpcups" and the "hpijs" versions, since hpcups is new, its rasterization is different, and YMMV. If one proceeds with the HPLIP installation, the gz'ed ppd's are also placed into /usr/share/ppd/HP
  • Before doing so, use Synaptic to install developer versions of libjpeg, libcups, libusb1, and libsane to avoid ./configure fails. My final HPLIP configure line was $ ./configure --prefix=/usr --enable-lite-build --disable-network-build. I only needed scanning and printing, and via a USB connection.

Pt 2 errors

This make proceeded along for a while until exiting with
prnt/hpcups/CommonDefinitions.h:43:25: fatal error: cups/raster.h: No such file or directory
I installed apt-file (# apt-get apt-file find) and sought out the raster.h code. Sure enough, it was located:
$ apt-file search cups/raster.h
libcupsimage2-dev: /usr/include/cups/raster.h
lsb-build-base3: /usr/include/lsb3/cups/raster.h

So accordingly...
# apt-get install libcupsimage2-dev
...and back to the compiling. I have to hand it to whomever came up with the excellent idea of apt-file. The remainder, including # make install, appeared to go normally.

next errors

To check the installation...
$ hp-check -t
The program 'hp-check' is currently not installed. You can install it by typing:
sudo apt-get install hplip
Perhaps some library linking did not go well, $PATH was not updated, or files were installed into a non-standard location for the PATH or CUPS. The latter is what happened during a prior HPLIP install in 2011.
$ ls /usr/bin |grep hp
dvihp
hp-mkuri
php
php5
pitchplay
Not encouraging.
$ which hp-check
$
Not encouraging.
$ find -name hp-check
$
Not encouraging.
# service cups restart
cups stop/waiting
cups start/running, process 11411
$ hp-check -t
The program 'hp-check' is currently not installed. You can install it by typing:
sudo apt-get install hplip
Not encouraging.
# reboot
$ hp-check -t
The program 'hp-check' is currently not installed. You can install it by typing:
sudo apt-get install hplip
Not encouraging.

uninstalling HPLIP

Link: Uninstall instructions. From the installation directory...
# make uninstall
( cd '/usr/share/cups/drv/hp' && rm -f hpcups.drv )
( cd '/etc/cron.daily' && rm -f hplip_cron )
( cd '/usr/share/hal/fdi/preprobe/10osvendor' && rm -f 20-hplip-devices.fdi )
( cd '/usr/share/ppd/HP'...all ppds)
( cd '/etc/udev/rules.d' && rm -f 56-hpmud_support.rules 86-hpmud_plugin.rules 56-hpmud_add_printer.rules 55-hpmud.rules )
( cd '/usr/share/doc/...various docs.)
( cd '/usr/share/doc/hplip-3.13.3/styles' && rm -f css.css )
( cd '/usr/share/doc/hplip-3.13.3/images' && rm -f favicon.ico print.png toolbox_actions.png toolbox_fax.png toolbox_print_control.png toolbox_print_settings.png toolbox_status.png toolbox_supplies.png xsane.png )
( cd '/usr/share/doc/hplip-3.13.3' && rm -f COPYING copyright README_LIBJPG )
( cd '/usr/lib/cups/backend' && rm -f hp )
( cd '/usr/bin' && rm -f hp-mkuri )
( cd '/usr/lib/cups/filter' && rm -f hpcups )
( cd '/usr/lib/cups/filter' && rm -f hpcupsfax )
( cd '/etc/hp' && rm -f hplip.conf )
This is where HPLIP had been installed. I don't believe the HAL issue will be important, but we'll see. Additionally, from the uninstall, we have some idea what libraries were installed and why they might not have been located...
/bin/bash ./libtool --mode=uninstall rm -f usr/lib/libhpmud.la'
libtool: uninstall: rm -f /usr/lib/libhpmud.la /usr/lib/libhpmud.so.0.0.6 /usr/lib/libhpmud.so.0 /usr/lib/libhpmud.so
/bin/bash ./libtool --mode=uninstall rm -f '/usr/lib/libhpip.la'
libtool: uninstall: rm -f /usr/lib/libhpip.la /usr/lib/libhpip.so.0.0.1 /usr/lib/libhpip.so.0 /usr/lib/libhpip.so
/bin/bash ./libtool --mode=uninstall rm -f '/usr/lib/sane/libsane-hpaio.la'
libtool: uninstall: rm -f /usr/lib/sane/libsane-hpaio.la /usr/lib/sane/libsane-hpaio.so.1.0.0 /usr/lib/sane/libsane-hpaio.so.1 /usr/lib/sane/libsane-hpaio.so
( cd '/usr/lib/cups/filter' && rm -f pstotiff )
We'll see if we can get by without these libraries, eg, may not be able to do scanning. Still, simple printing, to start. A decent PPD should be sufficient.

Pt 3 Printer Installation (10 minute)

Note: "udevmonitor" is now "udevadm monitor".
1. Uncompress the ppd wherever you find it as a .ppd.gz from the HPLIP source (no need to compile HPLIP)
2. Copy it to where it can be found and chmod it.
# cp hp-officejet_pro_8500_a910.ppd /usr/share/cups/model/1sttry.ppd
# chmod 644 /usr/share/cups/model/1sttry.ppd
3. Verify you the user are in the groups lp and lpadmin, eg via "$ groups" or "# userconfig"
4. Verify the file /etc/cups/cupsd.conf has the line (or add it and restart CUPS):
FileDevice Yes
5. Run # udevadm monitor
6. Connect printer into USB, write-down dev address eg, usb:/dev/usb/lp0 that appears.
7. Be sure CUPS is running, eg # service cups restart
8. Add the printer to that USB address.
# lpadmin -p hp8500 -E -v usb:/dev/usb/lp0 -m 1sttry.ppd
9. Print, profit
10. If problems occur, see my post from 2011. You might have to uninstall the printer and try a different PPD or a different location for the PPD. The command to cancel current print jobs is # lprm -, the command to remove the printer (eg, named 'hp8500' above): # lpadmin -x hp8500. Also # lpstat -v is your friend.

One additional error

Uninstalling the HPLIP libraries earlier above did come back to bite. Everything installed properly, but when attempting to print, an error: "/usr/lib/cups/filter/hp/cups not available: No such file or directory". I then reinstalled HPLIP but installed PPD manually. Appeared all good, but print jobs gave error that printer was waiting to become available. Looked into /var/log/cups/error.log, and noted the following
The name org.freedesktop.ColorManager was not provided by any .service files
This appears to be a common error. By now, I also saw a lot others pissed off about the various security (non)interactions around loopback security and their distro. For example, this person's SuSE rant.

Incidentally, I noted that, in each case, a gnome keyring error appears, stopping communication with the printer. Apparently, a person has to hack their own laptop(!) for normal use if they use Ubuntu/Lubuntu. The roots of gnome-keyring persist into PAM, of course, and the LDAP abortion in their own system. To avoid contributing to my own productivity loss past the 12 hours already lost here, I eventually installed the HP5800a with "apt-get hplip". At some point, I will return to Slackware but, before doing so, I will attempt to euthanize gnome-keyring, PAM, and whatever other interconnected encryption garbage is in this distro when I have a few days to spare and see if a printer can be attached.

Again, adding a printer is typically a console job of 10 minutes, but I just gave up and let the immense Ubuntu RAM-killing daemon colluge do it for me after 12 lost hours. Google "cups pam" and you'll see why I gave up.

lpadmin

Lpadmin is part of CUPS and doesn't work when CUPS is not running.

GET A LIST OF PENDING PRINT JOBS BY INSTALLED PRINTER NAME
# lpstat

CANCEL ALL PENDING PRINT JOBS
# cancel -a

PRINT A TEST PAGE (eg, the man page for lpadmin)
# man lpadmin | lp -d HP8500

Saturday, March 9, 2013

[solved] incorrect duration converting wav's to mp3's

problem

User creates a 3:15 screencast "smite.mp4". They extract the WAV soundtrack to opitimize or edit it. After this, suppose they wanted to convert the WAV to a space-saving MP3 before recombining w/video? In this case, imagine a simple 192k continuous bitrate is OK, that no Variable Bit Rate (VBR) audio is required.

We do our conversion, say with:

$ ffmpeg -i smite.wav -ab 192k -af "volume=1.1" smite.mp3

Note: The volume was tweaked because it's sometimes decreased in conversion. Great resource.

but the duration is incorrect

Now we run a test of the MP3 file in some player, perhaps Audacious. On occasion, we'll find that the duration stamp is corrupted, perhaps appearing as 28:15. Typically, the slider can't move in a corrupted timeline either.

Incorrect duration stamps in media files are an occasional problem. The original media file might have it. More often if a person accelerate or slows-down the WAV, which we can do between half-speed (0.5) or double speed (2.0) with a filter.

$ ffmpeg -i smite.mp4 -af "atempo=0.85","volume=1.1" -vn -ar 44100 -ac 2 smiteslower.wav

the reason

Ffmpeg and avconv use the bitrate setting as part of their duration calculations. Both ffmpeg and avconv will calculate the duration correctly if we don't specify a bitrate. Unfortunately, if we don't specify the bitrate, ffmpeg and avconv will use their native bitrates, which both happen to be the low quality of 128Kb. So how do we achieve the 192K bitrate we desire in the example above and still obtain a correct duration stamp on the resulting MP3?

solution



Install lame. For example to achieve the 192Kb, with a correct time stamp, and with the conversion volume setting just a bit above 100% (scale), we could use:
$ lame --scale 1.2 -b 192 smite.wav

I can change the bitrate to whatever I want, even into a VBR, and the resulting duration stamp is accurate. With respect to the volume, if I wanted to double it, the scale I would select would be "2", and so on. Finally, the output file name, in this case smite.mp3, will be created automatically using the input WAV file's name. Alternatively, one can force an output name. Now, when we re-render our audio back to our video, they will be properly synced, since the timestamps are correct.

solution going mp3 to wav

$ lame --decode file.mp3 output.wav

memory issues

Sometimes there's not enough /tmp space to handle processing a large media file. You'd imagine the solution is to increase the size of /tmp beyond the Gb's of installed RAM, so that the system overflows into SWAP. This will not work. This is because they now have both /tmp AND /tmpfs. Tmpfs is what is actually being used. Its default is half the GB of RAM. Systems put tmpfs in RAM to save on resources -- it makes the system more efficient. However, when dealing with a large media file, I modify /etc/fstab as below, and then reboot.

# nano /etc/fstab
tmpfs /tmp tmpfs rw,nodev,nosuid,size=10G 0 0

Once I'm done with my media work, I comment out this line in the fstab and reboot again.

video note

When converting the video of a screencast, the only way I've found to get the proper duration is to be sure to use the switch:
-target ntsc-dvd

Tuesday, March 5, 2013

Repeat in gnome-mplayer

The old method was the command line switch "-loop 0" when invoking mplayer. This made the media file or playlist repeat. But in a newer installation of Lubuntu, I found that $ mplayer -loop 0 did not execute the file --- it simply returned errors about the "loop" switch. Two annoying hours later, the problem was fixed.

solution

The solution was to
  • install mplayer. Although it appeared I already had mplayer installed on my system, I did not. I had mplayer2 installed on my system and, of course mplayer2 has no repeat function, so that "loop -0" simply caused errors.

    Unfortunately, this took me an hour and a half to uncover. This was because, currently, mplayer2 is completely (and suspiciously - RIAA/MPAA influence?) disguised as mplayer. I was sure I had mplayer, not mplayer2, on my system. That is, the "/usr/bin" folder contained "/usr/bin/mplayer", NOT "/usr/bin/mplayer2". And typing "$ /usr/bin/mplayer" appeared to launch mplayer even though mplayer2 was being executed.

    Eventually I was able to discover what was going on via "mplayer --version". Not surprisingly, this returned information about "mplayer2" instead of mplayer -- the ruse was finally revealed.
  • Once the real mplayer was installed, I simply opened gnome-mplayer, went into its "preferences" and, under the "mplayer" tab, added the command switch "loop -0". Thereafter, media repeated when played.