View Single Post
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#3
".deb" format basics:

Basically, a .deb file is an archive of the same format that the "ar" utility uses, containing the following things:
debian-binary: A text file which roughly speaking, says what version of the .deb file format is being used. This will literally just have one line in it, the string/number: "2.0"
data.tar.gz: gzipped tar archive contains all of the actual files "belonging" to the package (which for my purposes is none, so this will just be an empty archive - if you want to leave actual scripts or suid binaries on your system as part as your method, those would go here: for example that's where the rootsh package stores its /usr/bin/root and /usr/bin/rootsh scripts).
control.tar.gz: gzipped tar archive contains the stuff used by dpkg/apt/HAM for the package management (which is where we would put our script, along with some text files that fulfill the minimal requirements for a valid .deb package - more on that later)

The first thing I did is set up a temporary working directory inside /tmp, and a subdirectory in that (the main working directory is used to store most generated files, but the sub directory is used as the place from which the .tar.gz files are built (it's the easiest way to make the file paths inside the generated archives work out correctly), then I made the empty data.tar.gz archive by cd'ing into that subfolder and doing "tar -czf" with "./" as the only path to archive.

Then we need to make three required control files for a minimal Debian package: changelog, control, and copyright. These might not all be required for dpkg/apt/HAM to properly install them, but I prefer to generate packages that conform to the Maemo packaging guidelines (which mostly say 'follow the upstream Debian guidelines'). After that, we need to make the actual script file that will be ran when installing the package we generate.

The changelog file contains a record of the changes to the software. Since the actual package is automatically generated, and otherwise has no real 'changes', I just make it have a single 'change' logged, the initial creation (replace "[TIMESTAMP]" with the time printed by running 'date -R' at the moment that the text file was generated):
Code:
root (1.0) unstable; urgency=low
  * Automatically generated from script!

 -- nobody <nobody@example.com>  [TIMESTAMP]
..note that in both this file and the next one, I use "nobody" as the author/maintainer name, with nobody@example.com as their email. I did this so that it's clear that the package isn't actually maintained by anyone and that it's an automated one. But you could put yourself or something, or whatever makes sense to you here. Also, note that "example.com" is one of the ONLY domain names guaranteed to never be used/registered by the relevant standards, hence why it's safe to use for a not-real address, and except for possibly testing/demos confined to specific local networks, no sane environment should ever be configured to route that domain anywhere. Virtually any other hostname you could make up can someday be registered/routable-to (especially now that arbitrary gTLDs are possible).

The control file contains the meat of the actual '.deb' metadata: this is what tells the underlying packaging system parts what the package name is, what 'section' it goes under, who the maintainer is, etc. With all of the minimally required fields, it looks like this:
Code:
Source: root
Section: user/admin
Priority: extra
Maintainer: nobody <nobody@example.com>
Package: root
Architecture: all
Version: 1.0
Depends: 
Description: Adds basic rules for sudo: password-protected root access.
..note that the exact section doesn't matter, BUT HAM will only install packages from sections that start with "user/", so we have to pick one of those. I defaulted to "user/admin" because I thought "admin" was the best section choice based on upstream conventions, since for example "sudo" is in the "admin" section and having root access is an administrative thing. But since HAM refuses to install packages with the section "admin", "user/admin" was the next best thing.

Most of the other values can really be whatever (so long as they are still valid for the debian control file specification), but in this example I picked values that make sense and/or are most appropriate relative to Debian+Maemo packaging guidelines, and for the actual package name, I just picked "root" because it's short and sweet and to the point: it provides general ability to run things as root. I initially called it "rootmyself" though, because it was more unique and fit more thematically with what the whole package is about. So, you know, call it whatever you want.

Finally, there needs to be a copyright file, but much like the changelog, it really doesn't matter what you put in it: This is just the copyright which applies to the package itself, and since I'm basically sharing everything needed to generate this package here freely, and it's commonly available knowledge anyway, I figured in my case that just saying it's in the public domain was the best choice:
Code:
These auto-generated package contents are in the public domain.
Okay, so that gets the .deb control-files over with. Then we take the above script from the previous post, or whatever your particular flavor of modify-my-system-to-give-me-root-access you want, and make that our preinst script. You can also use 'postinst', and the result would honestly be virtually the same: as I understand it preinst is ran right before the data.tar.gz is unpacked, and postinst is ran right after that, but since data.tar.gz is empty and the whole point of this package is to just have our script executed by the package manager, it doesn't really matter too much.

So to build the control.tar.gz from the files we've just generated, we want to make the preinst script executable, then we simply tar and gzip those files (control, copyright, changelog, and preinst/postinst) into control.tar.gz. Then we can remove the subdirectory in our working directory, as we won't need it anymore.

Finally, we also create the debian-binary file, which as aforementioned, simply contains the string "2.0".

And now it's time for the fun/key part: manually-build-ar-file process
__________________
If you want to donate in support of anything that I do, you can do so with either of these options:
PayPal | Bitcoin: 1J4XG2z97iFEKNZXThHdFHq6AeyWEHs8BJ | [Will add other donation options eventually]

Last edited by Mentalist Traceur; 2015-01-19 at 11:53. Reason: Edit1: Adding links back to prior/next post. | Edit2: Fixing links
 

The Following 13 Users Say Thank You to Mentalist Traceur For This Useful Post: