Sharing a shell and monitoring the other party

Recently, I had a reason to allow someone else to use a shell on a machine for which I'm the admin, but I wanted a way to track what they're doing. You might think the history command is just fine for this, but it's possible to clear the history, and I wouldn't want that. Screen to the rescue!

I ssh'd into the machine and created a new user for my visitor. Then I switched to that user. Once logged in, I ran screen -L, which logs the shell (both input and output) to ~user/screelog.0). Then I called up the user, gave them the IP address, username, and password. They logged in, and I told them to run screen -ls to see a list of open screen sessions. The output looks like this:

There is a screen on:
 2119.pts-0.marlyn (09/01/2010 06:32:03 PM) (Attached)
1 Socket in /var/run/screen/S-maco.

The next step was for them to type screen -x 2119.pts-0.marlyn Once they did this, we could each see what the other saw in our SSH session, and it was all logged. Great! I could keep track of what they were doing as they were doing it and review the logs later for a double check.

It's not a VCS though. If you know what directory they'll be operating in, you might want to run bzr init ; bzr add ; bzr commit -m "starting point" first, so you can later run bzr diff | less to see what files changed and keep a record of what changed, since while it might all seem perfectly logical while it's happening, recalling the exact changes won't be easy. The point of watching can be to catch them in the act if they try to do something that violates your security policy or to be given a demonstration.

EDIT: After a question in comments about how you keep them from opening another non-screen'd connection, my friend Peter suggested adding screen -xR to the user's ~/.bash_profile, so it forcibly connects to the screen session. Thanks, Peter!

ZaReason Terra HD

Jono wrote about his new ZaReason Strata, and Rich wrote about his new ZaReason something-else, so I figured I'd let you all know about the ZaReason Terra HD I said I wanted to order, now that I've had it about a month.

Typing has turned out not to be a problem. This makes sense, if you compare the size of the keyboard to the one on my other ZaReason laptop, a 13" they sold in 2008 under the moniker "UltraLap," but which I call Betty. The only diffrence in width is the extra column of home/pgup/pgdn/end keys, which are Fn keys on this keyboard, and I got used to the gaps between keys.

What's confusing me the most is that this has the Ctrl on the far left of the bottom row and Fn to the right of it, while on my old Gateway (Ada) and Betty have Fn on the corner and Ctrl to the right of it. I use Marlyn (the Terra, named after Marlyn Meltzer, another ENIAC programmer) a lot when on the bus to/from work, though, so it's actually on the other laptops that I screw up a lot. Oh, can you guess which thumb I use to type space?

"Why do you use it on the bus to/from work?" you may ask. Well, it has a 3G modem built in! So, within an hour of taking it out of the box, I found myself at the T-Mobile store signing up for a SIM card. Some people say "eww, T-Mobile," but they're charging $40/mo for 5GB bandwidth that when exceeded just gets slower, while AT&T wants $35/mo for 2GB followed by overage fees or $60 for 5GB followed by overage fees. Easy choice there! Oh, and the other night when CopyNight was held at Teaism in Penn Quarter (yummy food, recommended!), I was the only one with reception in the basement. That's where I was when I posted the last blog post, actually. I like being able to IRC from the bus! This will be very handy when I'm at a family reunion next weekend with no wifi and Ohio LinuxFest (where I am speaking) the weekend after that, since the conference center always wants to gouge OLF for Internet access by charging thousands of dollars more than the con can afford to pay to provide access to attendees (resulting in wifi being unavailable).

The one little thing bugging me is the MacBook-like lid. That is, it can't be laid out all the way flat like my other laptops' lids can. MacBooks always make me worry that someone is going to throw a shmooball or other projectile, hit the screen, and either A) snap it off or B) knock the laptop over. I hope B is more likely than A.

I got it with Kubuntu Netbook Edition pre-installed, though I have since upgraded to Maverick which doesn't differentiate between plasma-netbook and plasma-desktop at install-time (meaning I have both interfaces available and can press a button to switch). As far as I know, ZaReason is the only company pre-installing Kubuntu or really any KDE-based distro. When I ordered it, I told Jonathan Riddell (Canonical's Kubuntu hacker), and his first question was "what OS is it coming with?" I said "Kubuntu Netbook," and he boggled and requested confirmation that I was serious.

Not sure what else there is to say about it. With Firefox running and so refusing to let my SSD sleep (for some reason, Firefox writes to disk every few seconds) or give my CPU a break (yeah, don't get that one either), I get about 5 hours of battery life. I really wish Firefox wasn't such a resource hog. I may have mentioned before that they had a suspend/resume bug to fix before release. I actually ordered a red one and told them to send it unfixed, but the timing on red parts being shipped to the ZaReason shop was perfect for Canonical to inform them that some BIOS tweaks needed to be made and for them to get the parts manufacturer to do it before shiipping! So, I can reliably resume from suspend when I click the suspend button in the battery applet. This uncovered a new bug though: the fact that I have to click that button. I don't care, it's how I usually suspend anyway, and the "suspend if left alone and unplugged for >15 minutes" setting still works so it doesn't end up causing problems anyway.

More pretty photos! I don't think my camera did a good job of showing how metallic the lid is or the fact that the wrist area is slightly rubberised you get a good grip when holding it. Oh, and I love that the power cord plugs in on the side instead of in the back. I like to be able to see where I'm plugging things.

Oh yeah, I always see people comment on blogs where Linux-laptop vendors are mentioned that they wish there was a company in their country selling these. Guess what? ZaReason ships internationally!

Is packaging new software hard?

EDIT 1: Sorry Planet readers. I tried adding a "read more" thing to shorten it, but apparently that doesn't change the RSS feed, just the blog's front page. And yes, I will fix up the Ubuntu Wiki later.

A common answer to my question about why people aren't packaging is that packaging is hard and the wiki is kind of lacking. Debhelper 7 and Source Version 3.0 (the new Debian packaging format) make things a lot easier.

So is it hard? In the common case, no.

EDIT 2:Switched from "native" to "quilt" since as pointed out in comments, it makes for a smaller upload and debuild can deal with directly-applied patches in the case that you don't know how to use quilt.

Assuming the software you want to package uses something like Python distutils ( python setup.py build && sudo python setup.py install) or Autotools (./configure && make && sudo make install), Debhelper 7 makes things really straightforward.

Backing up, there are 4 files necessary in the debian/ directory:

• rules


• control


• copyright



• changelog

There are two more files you can include that act as a sort of metadata for what sort of package you're making:

• compat


• source/format

Assuming you want to make a Source Version 3.0 quilt package with Debhelper 7 (this is pretty normal these days):

1. Rename the original source tarball to have the form <package name>_<upstream version>.orig.tar.gz


2. Unpack the source and change into the unpacked directory: tar xf foo_bar.orig.tar.gz && cd foo



3. Make a debian directory and enter it: mkdir debian && cd debian/


4. Now it's time for those files

EDIT TO ADD

Generation

Good news: The version of dh-make in Debian SVN appears to support Debhelper 7.

Bad news It doesn't parse command line arguments properly.

In the meantime, you can use the old one to generate everything but the debian/rules file. If only a single deb will be produced, and it's under the GPLv3, that'd be dh_make -c gpl3 -s Then you'll just delete files not listed above and the debian/rules file and instead put in a debian/rules containing what I'm about to tell you below.

PS: I'm told dh_make is a pretty unclean way to do things. It's probably best if you just copy and paste the examples, then modify.

debian/rules

The boilerplate debian/rules file for standard build systems when you don't need to pass special configure options is:

#!/usr/bin/make -f

%:
 dh $@

Note that that is a tab, not a bunch of spaces, before the "dh". This used to be the most difficult file to write, which is why I used to use dh_make to generate it. Debhelper 7 made it so much easier!

debian/control

This one is long, but it's pretty easy to fill in the blanks. It's the only file of the bunch for which you might continue to need a reference. Here's how the control file should look:

Source: foo
Section: bar
Priority: optional
Maintainer: Foo <foo@example.com>
Build-Depends: eeny-dev, meeny-dev, miney, moe, debhelper (>= 7)
Standards-Version: 3.9.1
Homepage: http://foo-project.org

Package: foo
Architecture: all
Depends:  eeny, meeny, miney, moe
Description: does stuff
 Foo does stuff blah blah blah blah to make things easier for users to
 do whatever they need to do. Long description here.

Source package stanza

• Source: Put the source package's name. This should be the same as the package name on the orig.tar.gz.



• Section: For the list of valid Sections, see the Debian Policy Manual section on this. In Debian, you will put something like "non-free/kde" while in Ubuntu only the subsection (kde) is listed and the archive admins put it into the right section. In Debian, if the section is main, just list the subsection.


• Priority: "optional" is what you want for most applications. Again, see the Debian Policy Manual section on Priorities for other options.



• Maintainer: your name and email address if you are submitting to Debian, or if you are submitting to Ubuntu, put "Ubuntu Developers <ubuntu-devel@lists.ubuntu.com>"


• Standards Version: current one (as of August 2010) is 3.9.1, and you shouldn't be starting from an out-of-date one



• Homepage: the project's homepage

Binary package stanza

Now for the binary packages generated by the source package. For most applications, there will only be one binary package generated, but if there's more than one, just repeat the second stanza of this file once for each one, of course changing the values on each line.

• Package: name of the binary package (the deb). Use logical names. If there's only one, feel free to repeat the source package's name.


• Architecture:
  
  • all: if it can be built once and run anywhere (common for Python)
  
  
  
  • any: if it needs to be built everywhere
  
  
  • Otherwise, a list of architectures
  
  
• Description: put a short description after the colon that can fill in the blank at the end of "$PACKAGE_NAME _____" with a short verb phrase (< 80 characters). On the lines below, put the long description with a single space at the beginning of each line. If you want a blank line, put a space and a period.

Build-Depends and Depends

I kept skipping the bit about Build-Depends and Depends. For these, you want to list the names of other binary packages (not source packages!). If a particular version is needed, parentheses and mathematical symbols (like where I put "debhelper (>= 7)") are used.

Usually -dev packages will be in the Build-Depends since that's where header files are in Debian and Ubuntu while non-dev packages will be in the binary package's Depends. You don't need to figure this stuff out completely on your own. The upstream README and INSTALL files should list what libraries are needed. If they're not, complain to upstream about bad documentation!

If you don't know what package provides a certain library, sudo apt-get install apt-file &&apt-file update then use apt-file search to find what package provides it.

Notes

These are the required lines. There are more available in the Debian Policy Manual (I keep referring to that, huh? It's useful!), such as Recommends and Suggests. How do these compare with Depends?

• Depends: absolutely must be installed in order for the software to work


• Recommends: useful and common to have with the package but not completely necessary.



• Suggests: you want apt to notify the user that there's some other software that's kind of useful to use with it

Recommends are installed by default in Debian and Ubuntu nowadays, but some people disable them using sudo apt-get install --no-install-recommends foo, so the difference between Depends and Recommends is important. There are more less-commonly-used package relationships too, but you can read the Policy Manual for that.

PS: If you're packaging a Python app, "${python:Depends}" goes in the binary package's Depends line to avoid typing it all out.

I always find writing a good description to be the hardest part.

debian/copyright

The debian/copyright file is a pretty straightforward fill-in-the-blank.

This package was debianized by Your Name <you@example.com> on
Tue, 24 Aug 2010 20:05:25 -0400

It was downloaded from http://example.com

For the timestamp, run date -R and copy that in there. Make sure the copyrights are listed next, something like this (the COPYING or LICENSE file should have this at the top):

Copyright
© 2010, Author Name <author@example.com>

Double check this by running licensecheck -r in the top level code directory.

License:
The code files in this package are under the GNU General Public License
version 3:
    | This program is free software: you can redistribute it and/or modify
    | it under the terms of the GNU General Public License as published by
    | the Free Software Foundation, either version 3 of the License, or
    | (at your option) any later version.

    | This program is distributed in the hope that it will be useful,
    | but WITHOUT ANY WARRANTY; without even the implied warranty of
    | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
    | GNU General Public License for more details.

    | You should have received a copy of the GNU General Public License
    | along with this program.  If not, see <http://www.gnu.org/licenses/>.

    The full text of the GNU General Public License version 3 is available on
    Debian systems in /usr/share/common-licenses/GPL-3.

Depending on licensecheck's output, you may need to list multiple licenses.

debian/changelog

This is the easiest of the files that require you to do any thought. Run dch -i --create, fix your email name and email address to match who you are, and put in an explanation. In future, you'll just run dch -i to add another entry. Explain what you did to the package. In this case, it'll likely just be "Initial release" which is pretty simple. dch should set the right version number. It'll look something like:

foo (0:1.0-0ubuntu1) maverick; urgency=low

  * Initial release

 -- Your Name <you@example.com>  Tue, 24 Aug 2010 20:05:25 -0400

The first bit is the same as the source package name and will automatically be filled in. The part in parentheses is the package version. It is in the form <epoch>:<upstream version>-<debian version>ubuntu<ubuntu version>

If you're doing the initial packaging, the epoch is 0, and the upstream version will be automatically filled in from the .orig.tar.gz.

• Debian: Debian version will be 1


• Ubuntu: Debian version is 0 and Ubuntu version is 1



• PPA: put 0s for both of those and add +ppa1 (or +yournick1 or whatever)

Next comes the version of Debian or Ubuntu for which you are packaging. Leave urgency at low for now. You're packaging an app, not the kernel. It just affects how quickly the build servers get around to it, and abusing this field will make people Not Happy.

Other files

For the debian/source/format and debian/compat files, just run echo "7" > compat and mkdir source && echo "3.0 (quilt)" > source/format

Time to build!

The hard part is done, and that really wasn't very hard given it's pretty much just fill-in-the-blank the whole way. Now to build and test. My preferred way to test builds is to use pbuilder. It uses a minimal chroot, so your build-dependencies get tested too.

1. Install the build dependencies you listed in debian/control


2. sudo apt-get install pbuilder ubunt-dev-tools devscripts (If I missed any, tell me in comments)



3. Generate the source package: debuild -S—a .debian.tar.gz, a .dsc, and a .changes file will show up in the same directory as the .orig.tar.gz


4. Make a pbuilder to build your package: ln -s /usr/bin/pbuilder-dist ~/pbuilder-maverick && ~/pbuilder-maverick create—substitute in whatever version of Debian/Ubuntu you are building for (same as you listed in changelog)



5. Build the source package: ~/pbuilder-maverick build ../foo*.dsc—.debs will be output in ~/pbuilder/maverick_result

PS: The "make a pbuilder" step only has to be done once per release on which you intend to ever build. Keep it up to date with ~/pbuilder-maverick update

If it all builds successfully, congrats! If it doesn't, either you forgot a build dependency or it's not a wonderfully straightforward application and you should visit #ubuntu-packaging on Freenode or #debian-mentors on OFTC for help debugging. We're friendly!

Test

Install the debs and test it out.

Upload

You'll need to sign the package before you can upload it anywhere, if it didn't get signed when you ran debuild (the output would have told you if it did). Generate a GPG key and use debsign -k<your key ID> foo*.changes to sign it. If you're working on Ubuntu, add your key to Launchpad or if Debian add it to Debian Mentors. Then run dput mentors foo*.changes for Debian Mentors or dput revu foo*.chanes for Ubuntu's REVU (where new packages are reviewed by MOTU for inclusion in the archive). You'll get feedback from a mentor or a MOTU, improve your package based on that, and then someone will sponsor it. Or you can upload to a PPA with dput ppa:user/ppa foo*.changes

What are the barriers to walking the MOTU/Developer path?

I asked this on Ubuntu.StackExchange but only got 3 answers so far, so I wanted to put this a bit more publicly too. What keeps you from packaging, patching, etc? If you do those things, what keeps you from applying for upload rights?

About 150 people are members of lp:~ubuntu-dev right now. There are also a handful of people who haven't yet become MOTU or joined another developer team but do good work. More hands are always needed, so what's keeping the rest of you folks away from this area of contribution?

For reference, 150 is a pretty small number given about 30,000 packages. Debian has more like 1000 developers.

Feel free to answer here in the comments or on U.SE.

Kubuntu & Kubuntu Netbook 10.04.1 now available

The first point-release for Kubuntu and Kubuntu Netbook 10.04 is now available. If you've been putting off installing because of the number of updates you'll have to download, the good news is all updates, bug fixes, and security patches that have been released for these two versions of Kubuntu have been rolled into the new 10.04.1 disc images, saving you from spending hours on updates. Yay! Just visit the Get Kubuntu page on the new Kubuntu website to get yours.

If you're already running 10.04 and have been keeping up with your updates, you don't need to do anything. You're there!

Yes, there's updated Ubuntu ISOs too.

The Next HOPE

Last weekend was The Next HOPE (following from The Last HOPE) in New York City. HOPE stands for Hackers on Planet Earth and is a biennial conference put on by 2600: The Hacker Quarterly. The Wikileaks guy may or may not have shown up. Some online say he didn't. Someone else told me "oh yeah, he was sitting behind the Tesla stage drinking Club Mate all day Friday," so who knows. Apparently his keynote timeslot resulted in everything being timeshifted by one hour though. The physical security folks said he ran long. Though maybe it was a substitute who did so? I don't know. Kaminsky had another of the keynote slots, talking about SQL injection and the difference between programmer ways of thinking ("I'll just concatenate these strings here…") and programming-language-developer thinking ("We'll parameterize these, so they don't break anything…"). He made the very good point that the reason programmers ignore that parameterization stuff is that it's a pain in the neck to have to jump all around as you try to read the code figuring out "ok now insert first parameter…back up to code…second parameter…wait which one's the seventh parameter?" and outlined some ideas he has to make syntax programmers won't hate that can still fix the problem. And yeah, let's face it. Trying to escape every bad character is total Whack-A-Mole.

A group of librarians were here talking about how to get FOSS into libraries. They had a very important tip: brush your teeth. If you show up looking like a caricature of a hacker, it's a bit hard for the librarians to take you seriously. So, look like you've bathed since last Tuesday and know what a toothbrush is. Yes, they mentioned Evergreen.

Deb "freedeb" Nicholson from the Free Software Foundation spoke about why diversity is important to the growth of Free Software (hint: more diversity = more people!) and how to get there. In a similar vein, Nikki Neulist had a talk called "Hey, Don't Call That Guy A Noob: Toward a More Welcoming Hacker Community." She was talking about how new people provide new perspectives and if you're willing to just be helpful early on, they can end up really useful later. I think this is something we've tried to exemplify in the Ubuntu world, though I do still occasionally see some unwelcoming behaviour on IRC. Unfortunately, during her talk's Q&A, some guy thought it made sense to say tough cookies, this is our hacker culture and if your skin's not thick enough, you don't belong here. C4BL3FL4M3 and I started yelling at him from opposite sides of the room. How on Earth could "if you don't like our bad attitude, GTFO" fit in in a conversation about being welcoming? Why did he even attend if that's his attitude? Troll!

The Vintage Computing talk ended in me dragging a 14 year old I was showing around to the Borders across the street to buy her a copy of Hackers: Heroes of the Computer Revolution to give her more context about things like the Altair and the PDP-11.

There were talks on "Color, Light, and Perception" and "Cooking for Geeks." In the former, I learned that magenta does not exist as part of the white light spectrum. You will not find it with a prism. It's not a single wavelength of light but rather a trick in our brains when red and blue wavelengths overlap. I also learned about additive colours, which is what the RGB colour model we use for defining colours on a computer screen is based on. The reason I see white captions on a black background as red/blue-split (like when you look at 3D stuff without the glasses) when seeing it at an angle out of my glasses was also explained. Neat! The latter was about food science, a basic introduction to it, and a reference to there being more in the speaker's new book of the same title. Apparently the temperatures we're taught in food safety courses assume you're not hitting the coldest part of the meat, that your thermometer's wrong, and a bit more, so they're overestimated by a good 15°. Not that I eat meat or am interested in testing that. Time at temperature was brought up as well—the fact that reaching a temperature doesn't matter as much as maintaining that temperature for a decent amount of time. Various enzymes take various times to break down into something tasty. I think he said brussels sprouts were in the category of things that need to spend a good amount of time at high temperature to taste good. Someone should tell my mum this. Hers are too bitter.

I missed much of the "Simpson's Did It" talk, but I caught Mouse's segment where she talked about Mozart. Apparently "Miserere" by Gregorio Allegri was well-loved by the pope of his time. So well-loved, that he had analogue DRM on it! That is, no copies of the sheet music could be made without the pope's permission, period. Only two copies ever were, and they were for princes who had to promptly return them as soon as they finished. Additionally, the song could only be played during Easter week. What did Mozart do, knowing he couldn't get sheet music? Showed up, listened, memorised, and transcribed from memory. DRM broken! Thanks, Mozart!

If you want to write online about controversial topics and you find that your free speech is being harmed by those who do not want you to be heard sending false DMCA notices, you should know about Project DoD, a web host who is willing to send a counter-notice in response (apparently unlike most others). You still have the mandatory 10-day offline period while the counter-notice goes through, but at least it's not a permanent offline period. They're willing to fight for their clients. Lawyer Tiffany Rad (who was my carpool for the trip) and Chris Mooney were talking about this project of theirs.

I mentioned earlier taking a 14 year old around. She's a smart kid named Johannah, so I was introducing her to the other LinuxChix and other assorted cool people. I explained public key cryptography (the practical, not the mathematical theory) to her and showed her how to generate a GPG key. She's an Ubuntu user, so I got her uncle to pick up a copy of How Linux Works for her. It looks like an excellent book for her skill level. It starts out with basic command line stuff and goes on all the way through explaining bootloaders and system internals. Cool!

We attended a LinuxChix Lunch on Saturday, where the women who'd been there in 2002 for H2K2 were expressing surprise at how many women were present, saying LinuxChix would soon be obsolete. They said H2K2 had somewhere between 10 and 30 women total. Improvement was obvious. And by the way, yes, the hacking community does seem to have more women than the Free Software community. There was definitely a higher percentage of women here than even at SELF, which I've already said has more than I remember seeing at any other Linux event (uh, outside of LinuxChix events, obviously). Funny enough, when we got back, I ended up talking to some woman I'd never met who saw my panoramas on my screen and wanted to know how I took them. I told her about Hugin and Free Software and Ubuntu. Anyway, the "funny" bit is that one of the first things she said when asked how she liked the con (she'd never been to a hacker thing before, but her son was a speaker, so she showed up) was (paraphrased) "this is all very interesting, but I notice it's mostly male, and mostly Caucasian." Yeah…still got a ways to go.

I had a duty while I was there too. I was handing out postcards for Ohio LinuxFest to everyone I saw with a Tux, GNU, or distro logo on their shirt, laptop, or tattoo. There were a lot of Ubuntu users. At one point I thought I saw an Ubuntu laptop in front of me, but it was actually OSX.

Ubuntu Women t-shirt design + wallpaper

Probably a year or so ago, I made this design and submitted it as a possible Ubuntu Women t-shirt:

(download SVG source—you'll need the old Ubuntu Title font to render the SVG properly)

Today I requested SVGs of the new logos popping up around the *buntusphere, and Martin Owens had them all so went and modified my design. I think it's beautiful!

(download the SVG source —you'll need the new beta Ubuntu font to render the SVG properly)

He added flower petals around the logos, now that they're all perfect circles, and he even added a FLOSS flower to it! Love it! Lyz is looking into getting t-shirts made with this on it and how the Ubuntu trademark stuff factors in. Finally, Martin turned this into a really nice wallpaper:

All of the above is CC-BY-SA, but it's still subject to Canonical's Ubuntu trademark rules thanks to the Ubuntu logo in there.