[Jessie] Separating policy from binaries

[cseiler]

Hello,

I've already tested the Jessie packages on an existing image, and I noticed a small detail here: the piserial package contains both the binary piSerial for extracting the serial number of the device, as well as a hook into /etc/profile.d that does some automatic things (disallow any user to start an interactive shell except pi and automatically calls revpi-factory-reset unless a dotfile in pi's home directory exists).

May I suggest splitting the package up into two binary packages? (You could still build them from the same source package.) One containing both binaries (revpi-factory-reset and piSerial), and the other containing /etc/profile.d/revpi-factory-reset.sh? Because if I create a custom image, I might not necessarily want to have the same policy in place that you have on your default images (I consider the file in /etc/profile.d to be configuration policy), but I might want to have the piSerial command available.

Thanks!

Regards,
Christian

PS: By the way, the username check in that file disables "sudo -i" - without printing an error message, and without an error exit code, which left me wondering what just happened on the system. This might be intentional on your part, but I wanted to mention the effect.

[volker]

Christian,
just to make that clear: The material you are talking about is not officially released. There are still bugs and as we have published in the forum several times the official release will be next week by offering a download of the complete image. Our policy to let the community have insight into ongoing work by using GitHub for pre-released material does not mean that we would encourage you to use that material for your projects before it gets released.
Saying this I still want to thank you for making valuable proposals and for discussing stuff. But I think we should open a new forum for such "deep-in" discussions in order not to mix that up with the versions 99% of the community are working with. I will set up such forum the next days and shift both threads into this new forum (the other discussion was also based on several points which may not make it into the final releas of our Jessie image).
The functions you are discussing are part of our security strategy: We need to havily push users away from keeping the default password but instead using a unique one. When delivering complete devices we do thta job during the EOL-testing by generating a unique pw from the serial number and also changing the unique MAC of the eth0 connection to one of our own pool (which is pre-printed on the case). If people use a complete image from our server the MAC as well as the login PW is per default general and not unique. If users are not going to change this default this would be a high security riks for their system. The sw functions you are discussing are one way of forcing the users to do their job during the first login to the newly copied image. Users who do build their own image based on the GitHub sources may handle this security problem in their own way and are responsible for their way. So feel free to kick out or change any of those sources before compiling your image.

[cseiler]

Hello,

just to make that clear: The material you are talking about is not officially released.

Yes, I was aware of that, I apologize if I didn't make that clear in my original message. I was just trying to provide some early feedback to improve the experience for everyone.

Our policy to let the community have insight into ongoing work by using GitHub for pre-released material does not mean that we would encourage you to use that material for your projects before it gets released.

Of course. We are also not using this in any production environment yet. However, given that the release of an official image is around the corner, we thought it best to familiarize ourselves with the new environment early - and we are actually extremely grateful for your open approach here.

But I think we should open a new forum for such "deep-in" discussions in order not to mix that up with the versions 99% of the community are working with.

Again, I apologize, I simply assumed that the software forum was the right place for asking questions about the software itself. I'm happy to use the new forum instead.

The functions you are discussing are part of our security strategy: We need to havily push users away from keeping the default password but instead using a unique one. When delivering complete devices we do thta job during the EOL-testing by generating a unique pw from the serial number and also changing the unique MAC of the eth0 connection to one of our own pool (which is pre-printed on the case). If people use a complete image from our server the MAC as well as the login PW is per default general and not unique. If users are not going to change this default this would be a high security riks for their system.

No worries, and I'm sorry if my message came around as a criticism of the script in general - that's not the case. I completely understand that this is a very useful thing to have in the default image you're providing. I was focusing on the use case where we want to use the software you provide but not necessarily a default image. Apologies if that didn't come across well enough.

So feel free to kick out or change any of those sources before compiling your image.

Sure, and that's what we're going to do in this case.

What I was trying to suggest was the following: the "piserial" package provides the "piSerial" program and the integration into /etc/profile.d. And I'm completely fine with both being available in the base image you're providing. But in a custom image we'd like to have your official repositories enabled, and also have the "piSerial" program available, but not necessarily your integration script. For this reason my suggestion was to separate this into two binary packages: one containing the "piSerial" program itself, and the other containing the /etc/profile.d integration script. This way, your default image could contain both binary packages, but we could cherry-pick only the one with the "piSerial" program.

Again, I am sorry if I haven't communicated that clearly enough and have caused some misunderstandings.

Regards,
Christian

[lukas]

Hi Christian,

no reason at all to apologize for providing valuable feedback.

disallow any user to start an interactive shell except pi and automatically calls revpi-factory-reset unless a dotfile in pi's home directory exists

Okay the former is actually a bug, other users except for the pre-configured user "pi" should always be allowed to log in. I've now replaced "exit" with "return" in that script and just pushed a rectified version of the deb-package to the apt repo. Thanks a lot for pointing that out.

The intended policy is that upon first login (regardless if this is on the console or via ssh), user pi is forced to change the default password "raspberry" to a unique password (as well as change the MAC address). That's really the *only* purpose of the script. The dotfile /home/pi/.revpi-factory-reset is merely used as a flag to indicate that the password has been changed.

If you intend to burn an image on RevPis you ship to your customers and you're fine if they all share the same password, the simplest solution is probably to fork our imagebakery repo on GitHub and amend customize_image.sh to pre-create the dotfile.

Does this work for you or do you still consider it a problem if /etc/profile.d/revpi-factory-reset.sh and /usr/bin/piSerial are bundled up in the same package?

By the way, the username check in that file disables "sudo -i" - without printing an error message, and without an error exit code, which left me wondering what just happened on the system. This might be intentional on your part, but I wanted to mention the effect.

Hm, that's odd, did you perhaps install the jessie piSerial package on a wheezy system and then invoke "sudo -i" without creating the dotfile /home/pi/.revpi-factory-reset first?

Thanks!

[cseiler]

Hi Lukas,

Okay the former is actually a bug, other users except for the pre-configured user "pi" should always be allowed to log in. I've now replaced "exit" with "return" in that script and just pushed a rectified version of the deb-package to the apt repo. Thanks a lot for pointing that out.

Ah, then this code makes a lot more sense to me.

The intended policy is that upon first login (regardless if this is on the console or via ssh), user pi is forced to change the default password "raspberry" to a unique password (as well as change the MAC address). That's really the *only* purpose of the script. The dotfile /home/pi/.revpi-factory-reset is merely used as a flag to indicate that the password has been changed.

If you intend to burn an image on RevPis you ship to your customers and you're fine if they all share the same password, the simplest solution is probably to fork our imagebakery repo on GitHub and amend customize_image.sh to pre-create the dotfile.

Does this work for you or do you still consider it a problem if /etc/profile.d/revpi-factory-reset.sh and /usr/bin/piSerial are bundled up in the same package?

Well, we mainly wanted to get rid of the file because of the "exit" call, but if that was not intended anyway and is replaced by a "return" now, and other users can actually login, then yes. The only thing we would rather not do is modify that file manually (even though it is a conffile), because we don't want to run into problems with updates of your software later. (Because if you modify that to do something else, any non-interactive update would either keep our version or replace it with your version, and both are not necessarily the outcomes we want.)

So yes, this would also be perfectly fine for us, now that you've replaced "exit" by "return".

Thanks for solving this!

By the way, the username check in that file disables "sudo -i" - without printing an error message, and without an error exit code, which left me wondering what just happened on the system. This might be intentional on your part, but I wanted to mention the effect.

Hm, that's odd, did you perhaps install the jessie piSerial package on a wheezy system and then invoke "sudo -i" without creating the dotfile /home/pi/.revpi-factory-reset first?

Well, we did a dist-upgrade to Raspbian Jessie first (but kept the kernel), and then updated the Kunbus packages.

But apart from that: "sudo -i" sources /etc/profile.d as root (it's as if you'd login as root), so the "exit" call is what actually hit us. Replacing that with return also makes "sudo -i" work again.

Thanks again!

Regards,
Christian

[lukas]

Ok great.

May I ask, how were you able to perform a dist-upgrade despite the puny 4 GB eMMC? I'd expect /var/cache/apt/archives to overflow, did you mount that on a USB stick? Initially we'll only post a tutorial to upgrade by flashing a new image, but we intend to follow up with another tutorial to perform an in-place upgrade as is customary on Debian. Did you run into any non-trivial issues apart from the missing factory-reset dotfile?

Thanks!

[cseiler]

May I ask, how were you able to perform a dist-upgrade despite the puny 4 GB eMMC?

I didn't do anything special. This was mostly the stock image as we got it from you (I think I installed the command line editor "joe" beforehand).

I just checked /var/log/apt/history.log, and it did run out of disk space while it was trying to unpack or configure libperl4-corelibs-perl, so after an initial apt-get dist-upgrade, I had to do apt-get -f install libperl4-corelibs-perl (+ followed by an apt-mark auto libperl4-corelibs-perl to make sure that's not marked as manually installed) to fix that issue, then I did an apt-get clean again, and then a second apt-get dist-upgrade worked. (Obviously it will vary at which specific package this fails, depending on how much space is actually free.)

(Note that in the initial upgrade I only replaced the source.list for Raspbian, not for the Kunbus packages, those came later.)

In its current state (upgraded Raspbian + upgraded Kunbus, but not upgraded kernel), there's 605 MiB free space on /, with ~ 150 MiB used space in /home and 180 MiB in /usr/local. Those additional 330 MiB were not used at the time of the upgrade though.

I'd expect /var/cache/apt/archives to overflow,

No, that wasn't a problem. the entire upgrade did fit in there. (I mean the *.deb files.) I do remember doing apt-get clean before and after the dist-upgrade - and in between both invocations of dist-upgrade, but that's about it.

did you mount that on a USB stick?

No, no external storage at all, just the internal eMMC.

Did you run into any non-trivial issues apart from the missing factory-reset dotfile?

• The wheezy Pictory (or at least the default webpage in the browser) doesn't work with the Jessie (possibly related to the Apache 2.2 -> 2.4 transition?). What happens is that it constantly redirects to the index page, and that occurs due to the JavaScript code doing the redirect to login page logic also on the index page itself.
• During upgrade there were quite a few conffile upgrade questions. Most were related to changes made by Kunbus to the Wheezy default configuration. See below for a list of files that were affected. In all cases I had to manually merge the configuration files because some settings of Kunbus I wanted to keep, others I didn't. As neither package being upgraded used ucf, there was no automatic three- way-merge, so I had to do the merge manually.
• I never attempted to update the kernel (yet), so I don't have any experience there. (I figured that 4.1 was new enough to work for now, as Debian Jessie comes with 3.16 anyway.)
• I got a couple of debconf questions during the upgrade, apart from the conffiles. I don't remember them, unfortunately.
• After installing the Jessie pictory, that worked, but the config.rsc file it generates causes the piControl.ko kernel module that comes with the Wheezy image to crash. (Null pointer deref.) If one doesn't access the process image after that crash, one can still reboot the system cleanly - but trying to access /dev/piControl or unloading the driver will effectively freeze the system. (One can still login, but there will now be unkillable processes around, that even kill -9 won't be able to get rid of.) If one modifies the JSON files manually to not contain the "GUID" : " ...", "extend" : [] and "Connections" : [] settings in the main Pi module area, then the modified file does work, and at least a DIO module works fine. (That's the only one we currently have.) I expect this problem to go away when I upgrade the kernel and the piControl.ko driver.
• I did disable the DHCP client (via update-rc.d disable dhpcd if I remember correctly) and I did give the Pi a static IP (in /etc/network/interfaces) before I did the upgrade. This was unrelated to the upgrade itself, and the default DHCP/LLMNR is good; in our case a static IP for that specific box was just easier. Thus I have no idea how that functionality would behave on updates.

GUI does work, even with Jessie, but apart from logging in I haven't really tried that (and disabled it). I haven't yet tried the logi.RTS at all (neither the original Wheezy image nor Jessie).

Files where I got dpkg conffile questions during upgrade from Raspbian packages:

• /etc/ca-certificates.conf
• /etc/xdg/openbox/LXDE/rc.xml
• /etc/skel/.bashrc
• /etc/network/interfaces

Files where I got dpkg conffile questions during upgrade from Kunbus packages:

• /opt/KUNBUS/pictory/projects/_config.rsc.dpkg-old
• /var/www/data/login.json.dpkg-old

(Obviously if other people modify more than we did, then they'll get more conffile questions - but these questions were asked even when starting just from the stock Kunbus Wheezy image as it was preinstalled on the .)

That all said: once the official Jessie image is available, we'll likely replace the current installation with a new image - and after we've developed a workflow for creating custom images, using those.

Regards,
Christian

[cseiler]

Quick update:

I haven't yet tried the logi.RTS at all

That just works fine after the upgrade. (With the Jessie version of the package.)

Regards,
Christian