Packaging an automated login

xlo­gin

Hav­ing a Linux sys­tem auto­mat­ic­ally log in to a graph­ical pro­gram on boot is sur­pris­ingly dif­fi­cult. Com­mon solu­tions involve set­ting up a dis­play man­ager with cus­tom con­fig­ur­a­tion and it gets messier from there. For­tu­nately there is a bet­ter way, xlo­gin uses sys­temd to launch X for a given user.

The developer describes it as a stop-gap work­around but after four years it is still a lead­ing solu­tion. xlo­gin con­sists of two sys­temd ser­vices, a launch­ing wrap­per script, and a xinitrc con­fig tweak. If it is a hack it is a very eleg­ant one, the four files together come to just forty lines (31 if you remove com­ments and whitespace).

Unfor­tu­nately it’s not pack­aged for Debian, while shov­el­ling some files on to the disk works as a short term meas­ure in the long run I really need it to be pack­aged, it greatly helps the image gen­er­a­tion and allows long term main­ten­ance. So I pre­pared a quick ugly pack­age. It cur­rently has some issues that like bad source pack­age gen­er­a­tion don’t impact me but need to be fixed, I’ll clean it up and look and sub­mit­ting it in a few weeks.

Pack­age Managing

To feed the pack­ages in to multistrap requires a Debian repos­it­ory. Fun­da­ment­ally this is a http or ftp dir­ect­ory tree with a few spe­cially format­ted files. There are a pleth­ora of tools to assist cre­at­ing this but as is com­mon when there are lots of tools doing the same job, none of them stand out as been con­sid­er­ably bet­ter than the oth­ers. I chose to use reprepro, it isn’t easy to set up but blindly fol­low­ing online guides worked for me.

Keyring Man­aging

Debian signs all of it’s pack­ages as a basic assur­ance meas­ure. The Debian tools take some con­vin­cing to run unsigned pack­ages so it is easier when build­ing your own pack­ages to sign them too.

Sign­ing is the easy half. You gen­er­ate a gpg key, feed it to reprepro and it signs all the pack­ages it delivers.

Where things get a bit more com­plex is get­ting the pub­lic key in to the cli­ent com­puter so that it can verify the key. The quick solu­tion is to push the key in to apt-key when gen­er­at­ing the image. This works but is dif­fi­cult to maintain.

The more com­plete solu­tion, which Debian uses for it’s own pack­ages, is to cre­ate a keyring con­tain­ing all the valid keys. This keyring is then pack­aged and dis­trib­uted through the pack­age man­age­ment sys­tem. Struc­tur­ing it this ways allows keys to be added or revoked as required by push­ing a pack­age update. Doub­ling down the com­plex­ity, man­aging the keyring pack­age is a cluster of pro­grams called jet­ring which provide tracab­il­ity of changes.

I built my own keyring pack­age, lodlabs-keyring based on debian-archive-keyring which I dis­trib­ute through my devel­op­ment pack­age man­ager. With this setup I can feed multistrap cus­tom pack­ages at will.

A quick note, using this tech­nique multistrap must be able to acquire the keyring pack­age itself. So the image gen­er­at­ing machine must tie apt in to the private repos­it­ory and have the keyring installed.

Cre­at­ing your own keyring package

For a very small simple pack­age cre­at­ing your own keyring is a bit of work.

For starters, you need the basics:

apt-get build-depends debian-archive-keyring
apt-get source debian-archive-keyring

The debian-archive-keyring has a few directories:

  • keyrings:
    This con­tains the gen­er­ated keyrings, the end products. They are cre­ated by the Makefile.
  • active-keys, removed-keys, team-members:
    Each of these dir­ect­or­ies con­tains a col­lec­tion of keys.
    The keys are of a cus­tom file format, gen­er­ated by jet­ring from a gpg key.
    Instruc­tions for cre­at­ing a key are in README.maintainer.
    There is also an index file with a check­sum for each key, this can be gen­er­ated by jetring-accept.
    Finally there is an index.gpg file which signs the index, this can be gen­er­ated by jetring-signindex.

    • active-keys:
      This keyring is used to verify the archive pack­ages and is dis­trib­uted in the gen­er­ated package.
    • removed-keys:
      This keyring is used to revoke pre­vi­ous act­ive keys and is dis­trib­uted in the gen­er­ated package.
    • team-members:
      This keyring is used by the pack­age gen­er­a­tion to verify the act­ive and removed keyrings. It is not dis­trib­uted out­side the package.

To pro­ceed you are going to need two gpg keys, you con prob­ably use the same key twice but it wouldn’t be advis­able. I gen­er­ated two dif­fer­ent sub­keys fol­low­ing the instruc­tions here. The act­ive sub­key is the one used to set up reprepro and sign your pack­ages. The team sub­key is your per­sonal sign­ing key.

Push the per­sonal key into the team key­chain, then the reprepro key into the act­ive key­chain by fol­low­ing the instruc­tions in debian-archive-keyring’s README.maintainer.

Once your keys are in the pack­aging key dir­ect­or­ies, delete all the other keys in active-keys and team-members. Edit the index files so that only your key entry remains. Then resign the index by run­ning jetring-signindex over each folder.

You can also delete all the keys in removed-keys, cre­ate an empty index file and sign it with jetring-signindex.

Now if you run ‘make‘ it should gen­er­ate new keyring files only con­tain­ing your keys.

To com­plete the pack­age it will need to be renamed. Edit all the debian files, chan­ging every instance of debian-archive-keyring to your-keyring. The changelog, copy­right and con­trol files will all need to have por­tions par­tially rewrit­ten. The debian-archive-keyring script files in the debian folder will need to be renamed and the debian-archive-keyring instances in the Make­file will all need to be changed.

The gen­er­ated keyring files must be signed, run
gpg --armor --detach-sign keyrings/your-removed-keys.gpg

Finally invok­ing ‘debuild –b –uc –us‘ should spit out your-keyring_<year>.<month>_all.deb.

Screen Interface Prototype

While I have been rather neg­li­gent with my blog updates I have been kick­ing goals with pro­gress on the Grid-Eye thermal sensor, BananaPi screens and the user inter­face. Of these it is user inter­face that I am going to blather about here.

My primary goal of this pro­ject is to improve the microwave user inter­face, shift­ing away from four char­ac­ter seven seg­ment dis­plays to a more inter­act­ive fully fea­tured display.

Everything else, most of the work, is to sup­port and imple­ment this improve­ment. As I am now up to play­ing with the screens, select­ing screen sizes and touch inter­faces it seemed worth­while to spend a bit of time con­sid­er­ing what the GUI will actu­ally look like.

I did a few pages of pen­cil sketches, use­ful to work through a wide vari­ety of ideas.

Then I did a pro­to­type imple­ment­a­tion in HTML to iter­ate the bet­ter ideas. This pro­to­type is below, it is a fully inter­act­ive webpage — some bits pre­tend to work, other bits are stubbed out.

I would really appre­ci­ate it if people would play and give feed­back. It is designed for a fixed screen size of 480×800 pixels, the primary user inter­face will be fin­ger on a touch­screen, there will also be gen­eral web browser access for PCs and port­able devices.

View in new tab/window

The source code is avail­able on git­hub, it is pro­to­type code so there are more than few short­cuts and lots of poor practices.

My cur­rent design guidelines are:

  • Intu­it­ive to use
    • No instruc­tion manual or help pages
    • No advanced touch inter­faces (slid­ing, mul­ti­t­ouch etc.)
    • Large, obvi­ous, touch targets
    • Access­ible col­our scheme and aria support
  • For­giv­ing of mistakes
  • Not too hideously ugly

Choosing a touchscreen

When select­ing a touch­screen there is actu­ally an inter­est­ing choice that I have to make. There are two com­mon touch tech­no­lo­gies, res­ist­ive and capa­cit­ive, many people prob­ably know it as old and new touch­screens. (Inter­est­ing aside, capa­cit­ive screens actu­ally came first in 1965 but weren’t widely adop­ted, then res­ist­ive screens became com­mon before capa­cit­ive screens resur­ged with phones and became the “new” style.)

Res­ist­ive screens

A res­ist­ive screen works by let­ting you push one side closer to the other and detects this change.

Pro:

  • Elec­tric­ally simple, 4 wire sup­port built in to BananaPi A20 chip.
  • Cheaper to manufacture.
  • More accur­ate detec­tion than capa­cit­ive screens.
  • Will work if wet.
  • Will work if wear­ing gloves, using elbow or poked with a stick.
  • Plastic is scratch resistant.
  • Can option­ally detect pressure.

Con:

  • Easier to dam­age screen.
  • Dam­aged screen is use­less, minor dam­age typ­ic­ally causes com­plete failure.
  • Only sup­ports two sim­ul­tan­eous touch points.

Capa­cit­ive screens

A capa­cit­ive screen detects power loss to a nearby con­ductor such as a fin­ger. The mod­ern stand­ard is a pro­jec­ted capa­cit­ive tech­no­logy (PCT) panel which means a dir­ect touch isn’t required, this allows a pro­tect­ive glass layer to be inser­ted on the top of the screen assembly.

Pro:

  • More famil­iar to people.
  • Easier to clean.
  • Sens­it­ive PCT devices can detect fin­gers through insu­lat­ing gloves.
  • Sup­ports com­plex mul­ti­t­ouch patterns.

Con:

  • Fails if coated in a con­duct­ive mater­ial, such as sweat or food liquids.
  • Sens­it­ive to mech­an­ical design, the metal chassis is a con­ductor which can sig­ni­fic­antly impact on screen oper­a­tion and sensitivity.
  • Con­duct­iv­ity var­ies on the per­son, the person’s hydra­tion, ambi­ent humid­ity etc.

Fur­ther pontificating

So for some­thing port­able, like a phone, going capa­cit­ive is obvi­ously the bet­ter choice.

For a kit­chen appli­ance it is far less clear. Wear­ing dish­wash­ing gloves or smear­ing tomato sauce across the con­trols is going to be more common.

The big factor I keep com­ing back to is the famili­ar­ity. People expect to have a solid capa­cit­ive touch screen and attach a higher qual­ity value to it than a res­ist­ive screen. And that the lim­it­a­tions of the capa­cit­ive screen are well under­stood so people seem happy to work around them.

Basic­ally the engin­eer in me leans towards res­ist­ive, the mar­ket­ing orphan I recently adop­ted says capacitive.

So for now I’m get­ting both. I am already famil­iar with capa­cit­ive touch pan­els and have one com­ing as part of one of my screens. So I just need to acquire a res­ist­ive panel to play with and understand.

Shop­ping

Buy­ing a res­ist­ive panel is far harder than it should be… mostly due to lim­it­a­tions with the won­drous site alibaba.

<rant>
Alibaba is fant­astic for inter­act­ing with com­pon­ent sup­pli­ers but the search engine is abso­lute rub­bish, pre-Google Yahoo rub­bish. (As Yahoo used to own a sub­stan­tial chunk of Alibaba maybe it is lit­er­ally the pre-Google Yahoo rub­bish.) Essen­tially you enter some words, Yahoo searches for those words in the title of each product, the product with the most words in com­mon is the top of the list. Which means that the retail­ers cre­ate new duplic­ate product entries with dif­fer­ent titles try­ing to hold the bingo card that matches your search words. One touch­screen man­u­fac­turer had a single 4 wire res­ist­ive touch product, avail­able in about 15 dif­fer­ent sizes. They had roughly 1800 bingo cards/product entries try­ing to attract eyeballs.

(A nice trick with Alibaba dir­ect is that they don’t keep these all updated, so you can often get up to 20% off by find­ing a dif­fer­ently priced entry of the same product from the same manufacturer.)

Once I find a man­u­fac­turer I try to fig­ure out if I can trust them. A warn­ing trig­ger for me is any­thing that they are obvi­ously lying about in their mar­ket­ing, if there are obvi­ous lies I can see then there are prob­ably subtle lies that I can’t and will bite me later. With res­ist­ive touch­screens how­ever EVERYBODYalmost every­body lies, pos­sibly this is related to the above Alibaba is crap rant. And it doesn’t look like lies that help them, a 4 wire touch­screen has four ana­log pass­ive res­ist­ive wires, they state this, then in the inter­face sec­tion they state “RS232 or USB inter­face”… which I don’t under­stand. It clearly is a 4 wire FPC con­nector, there is no RS232 or USB plug in the pic­ture, no men­tion in the descrip­tion. I sus­pect there is a series of check­boxes box for inter­face and they feel the need to tick some­thing… Another odd one is they list a res­ol­u­tion, num­bers vary but all are wrong. It is an ana­log device, any res­ol­u­tion lim­it­a­tions come from the quant­iz­a­tion per­formed by the con­trol­ler, which they don’t sell. Why provide a fake num­ber and risk it being smal­ler than some­body else’s fake num­ber when the real answer is infin­ite and there­for bet­ter? *sigh*
</rant>

Buy­ing

I have reached out to three sup­pli­ers for fur­ther information:

I also found some inter­est­ing capa­cit­ive touch man­u­fac­tur­ers in case I go that route:

Return top