User avatar
JohnBeardmore
Posts: 211
Joined: Thu Nov 15, 2012 11:03 pm
Location: Derbyshire UK.
Contact: Website

Raspbian life cycle

Wed Jul 26, 2017 6:59 am

From the point of view of the embedded system designer, it's desirable to have an OS which can be patched to fix security issues etc, but it's also good not to have to do OS re-installs on all devices in a system too frequently, as the raw OS image needs a lot of customising.

So...

Is there a policy on how frequently there are major Raspbian releases?

Is there a policy on how long a release will be supported once superseded by the next?

Is there documentation of anticipated future releases?

Is there documentation of the release history of Raspbian?

Many thanks, J/.
Author of oBeMS open source Building energy Management System.
Automatic Meter Reading (AMR), Building Management System (BMS),
Building Energy Management System (BEMS), Infrastructure Control System (ICS).
See: http://t4sustainability.co.uk/oBeMS/

mattmiller
Posts: 2099
Joined: Thu Feb 05, 2015 11:25 pm

Re: Raspbian life cycle

Wed Jul 26, 2017 9:54 am

Is there a policy on how frequently there are major Raspbian releases?

Is there a policy on how long a release will be supported once superseded by the next?

Is there documentation of anticipated future releases?

Is there documentation of the release history of Raspbian
No
No
No
a little - not worth bothering with really

User avatar
RaTTuS
Posts: 10409
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK

Re: Raspbian life cycle

Wed Jul 26, 2017 9:59 am

raspbian follow debian so that's your best bet
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

User avatar
B.Goode
Posts: 8240
Joined: Mon Sep 01, 2014 4:03 pm
Location: UK

Re: Raspbian life cycle

Wed Jul 26, 2017 10:39 am

Is there documentation of the release history of Raspbian?
There are Release Notes going back nearly 4 years -

http://downloads.raspberrypi.org/raspbi ... _notes.txt]

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23338
Joined: Sat Jul 30, 2011 7:41 pm

Re: Raspbian life cycle

Wed Jul 26, 2017 11:37 am

Note there is a difference between Raspbian release and kernel releases. You can use more recent kernels quite happily on older Raspbian releases, so if you need a kernel security update, you will be able to get those. The latest tested kernels are made available under the usual apt-get upgrade options, or you can build you own from the Raspberry Pi github source - that's pretty easy.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
JohnBeardmore
Posts: 211
Joined: Thu Nov 15, 2012 11:03 pm
Location: Derbyshire UK.
Contact: Website

Re: Raspbian life cycle

Wed Jul 26, 2017 8:31 pm

Thanks all !

This query arises because of a project we're doing with a university. They require that,
"Network security on the Pi boxes ... needs to be ... compliant with University security policy. All standard accounts (eg "pi") must be disabled, and no direct root access. All access must be via named personal accounts or non-standard generic ones if you must". So far so good.

They then say "All access must be audited by the OS on each individual box". I'm not entirely sure what they mean by this, particularly 'audited'.

They continue, "Remote access will again be via the University VPN initially using a named ... account". Fair enough.

And now the interesting bit, "OS on the Pi boxes must be kept updated and patched at all times, and the OS itself must be current and within support lifecycle". For the various versions of Raspbian that we use then, we need to know which ones the RPF regard as 'current', i.e. supported with security patches etc, and ideally, when they will cease to be 'current' so we can schedule OS upgrades in advance.

They continue "Any out-of-date OS with any known vulnerabilities connected to the University network may be disconnected without notice". Fair enough, but this action would disable the heating controls in seven buildings and a small district heating network, and knock a students PhD project on the head. It would therefore be really great, to be able to get clear and definitive answers from the RPF to the above questions.

At a minimum, it would be great if the RPF could keep a web page which lists the following for each major Raspbian release:

1) date of first distribution,

2) when it is expected to be, or was superseded, and

3) when support (particularly security patches) is expected to cease or did cease.

I don't think telling them that it's 'kinda like Debian' is going to cut it. If they ask me 'is this a supported version of OS' I need to be able to give them an accurate answer, otherwise we all look a bit mickey mouse.

Many thanks, J/.
Author of oBeMS open source Building energy Management System.
Automatic Meter Reading (AMR), Building Management System (BMS),
Building Energy Management System (BEMS), Infrastructure Control System (ICS).
See: http://t4sustainability.co.uk/oBeMS/

Martin Frezman
Posts: 1020
Joined: Mon Oct 31, 2016 10:05 am

Re: Raspbian life cycle

Wed Jul 26, 2017 8:58 pm

Raspbian is basically "rolling"- meaning that if you do:

Code: Select all

apt-get update && apt-get dist-upgrade
on a regular basis (say, weekly, via a cron job), you will always be running the latest and greatest. For example, the transition from "Wheezy" to "Jessie" was accomplished this way, by many of the folks on this board, including YHN. You don't really need to "EOL" one version and start up (i.e., install) a new version, like you do with some distros.

So, unless I've missed something, that should solve your issues.
If this post appears in the wrong forums category, my apologies.

User avatar
JohnBeardmore
Posts: 211
Joined: Thu Nov 15, 2012 11:03 pm
Location: Derbyshire UK.
Contact: Website

Re: Raspbian life cycle

Thu Jul 27, 2017 1:33 am

That's interesting as an idea, but wasn't it the change from "Wheezy" to "Jessie" where they stopped reading inittab at boot time as they had a new way to start demons etc ?

While the new ways might be better, if you change something like that from a cron job, you run the risk that you'd break the system by never starting any useful processes again.

Ok, in the end you'd figure it out and fix it, but in the mean time you'd shut down seven buildings and a heat main. Could be unpopular.

For embedded applications you need stability and a chance to test the effects of upgrades.

I've heard that Ubuntu do an LTS version (Long Term Support). This appears to be available for the Pi, (see for example https://insights.ubuntu.com/2016/06/20/ ... -the-rpi2/).

It would be with great regret, but I wonder if I'd be better off using that in some ways.

Any thoughts folks ?

Cheers, J/.
Author of oBeMS open source Building energy Management System.
Automatic Meter Reading (AMR), Building Management System (BMS),
Building Energy Management System (BEMS), Infrastructure Control System (ICS).
See: http://t4sustainability.co.uk/oBeMS/

Martin Frezman
Posts: 1020
Joined: Mon Oct 31, 2016 10:05 am

Re: Raspbian life cycle

Thu Jul 27, 2017 3:38 am

All that you say is correct. And I don't think that anyone actually does the "update/upgrade thing in a crontab", for just the reason you mention - that you could wake up one day running a completely different (and most likely broken) system. But it is a theoretically correct way to achieve the goal of "keeping up with everything", which seemed to be chief among your requirements.

It seems you are correct that Raspbian is not the system for your needs. Unfortunately, it is the best supported (some might say the *only* really supported) system, as far as these support forums go. My experience with the Ubuntus is that they don't work as well as Raspbian, they seem to be less stable (I think the whole LTS thing might be x86 only), and, as mentioned, aren't well supported on this forum.

But it might be the way to go for your requirements...
If this post appears in the wrong forums category, my apologies.

Heater
Posts: 13087
Joined: Tue Jul 17, 2012 3:02 pm

Re: Raspbian life cycle

Thu Jul 27, 2017 4:02 am

My experience of Ubuntu is that it would be a step backwards in reliability when upgrading.

Certainly for any critical and/or remote system you don't want upgrades happening willy nilly according some cron job. Especially not dist-upgrades. Any change to any software or configuration has to be tested thoroughly first.

Although I must say Debian updates have been solid on my desktop machines for a couple of decades now.

In the extreme you will want to be building your own embedded Linux system up from scratch. Keep all the source and builds under your own control.

Another approach is to deploy your application and the libs it needs wrapped in Docker containers. A neat way of doing that is to use the services of resin.io.

runboy93
Posts: 352
Joined: Tue Feb 28, 2017 1:17 pm
Location: Finland
Contact: Website

Re: Raspbian life cycle

Thu Jul 27, 2017 11:28 am

Jessie not newest anymore, soon D:

User avatar
DougieLawson
Posts: 35793
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Raspbian life cycle

Thu Jul 27, 2017 2:19 pm

JohnBeardmore wrote:
Wed Jul 26, 2017 8:31 pm
This query arises because of a project we're doing with a university. They require that,
"Network security on the Pi boxes ... needs to be ... compliant with University security policy. All standard accounts (eg "pi") must be disabled, and no direct root access. All access must be via named personal accounts or non-standard generic ones if you must". So far so good.
How are they intending to handle the easy way anyone with access to the hardware can swap SDCards. The MAC address won't change but the stuff running on the RPi will.

So the malicious hacker does this:
1. Shut's down approved system
2. Boots up their rogue SDCard
3. Does bad stuff
4. Shuts down rogue SDCard
5. Boot up approved SDCard and walks away from a completely unaudited, uncontrolled, unlogged session.

It's much like pulling a HDD from a desktop machine which is then used for nefarious purposes.

If they really need strict control they're going to have to go with PiNet (although that still doesn't prevent the scenario above).
https://www.raspberrypi.org/blog/teaching-pinet/
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

User avatar
bensimmo
Posts: 4152
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: Raspbian life cycle

Thu Jul 27, 2017 3:39 pm

SD card problem could be address by a secure 'case' design where there is no access to it or the ports and it is not easily broken in to, etc. Just the needed cables can come out.

I noticed in the add/remove GUI updating option in the desktop it knows which are updates and which are security updates. I assume you can therefore specify apt to somehow only update security updates and not feature updates.
(Someone else may know)
This should keep it stable and stop raspbian tweaks altering things.

Maybe Raspbian isn't the OS for this situation?

Would this be something the Integrator team would look in to?

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23338
Joined: Sat Jul 30, 2011 7:41 pm

Re: Raspbian life cycle

Thu Jul 27, 2017 8:37 pm

Martin Frezman wrote:
Thu Jul 27, 2017 3:38 am
All that you say is correct. And I don't think that anyone actually does the "update/upgrade thing in a crontab", for just the reason you mention - that you could wake up one day running a completely different (and most likely broken) system.
Anything via apt-get will have been thoroughly tested., so should not result in a broken system.

Anything via rpi-update will be bleeding edge, and although a bit tested, not to the level of things that make it to apt-get
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Martin Frezman
Posts: 1020
Joined: Mon Oct 31, 2016 10:05 am

Re: Raspbian life cycle

Thu Jul 27, 2017 9:43 pm

Anything via apt-get will have been thoroughly tested., so should not result in a broken system.
Yes, usually.

But the issue here is that suppose you setup a system with the cronjob as I described earlier. Suppose further that you did this before the big Wheezy -> Jessie switchover. And suppose that you setup your system to auto-start mission critical processes via the /etc/inittab file.

Well, the next time you reboot after the big switchover, your system will be in a state that we, in the laity, would call "broken".

Note: For convenience, you might also want to assume that you setup your system to reboot automatically after each "apt-get update && apt-get dist-upgrade" operation (remember, we assumes you did this weekly via a cronjob). Now, you wake up on the critical morning and find your systems no longer working.
If this post appears in the wrong forums category, my apologies.

User avatar
PeterO
Posts: 4942
Joined: Sun Jul 22, 2012 4:14 pm

Re: Raspbian life cycle

Thu Jul 27, 2017 9:53 pm

Martin Frezman wrote:
Thu Jul 27, 2017 9:43 pm
And suppose that you setup your system to auto-start mission critical processes via the /etc/inittab file.
Have you ever run a "mission critical system" ? Anyone who does this for real for a living would never have an automated update process installing updates onto running, live systems.

That's what testing platforms are for, for testing updates before putting them on the live production platforms. No matter how much testing the OS provider does you always test your applications on an off-line setup to check for unexpected interactions between your particular applications and the OS.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
rpdom
Posts: 14985
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Raspbian life cycle

Fri Jul 28, 2017 6:54 am

PeterO wrote:
Thu Jul 27, 2017 9:53 pm
Martin Frezman wrote:
Thu Jul 27, 2017 9:43 pm
And suppose that you setup your system to auto-start mission critical processes via the /etc/inittab file.
Have you ever run a "mission critical system" ? Anyone who does this for real for a living would never have an automated update process installing updates onto running, live systems.
Exactly this. No way would I put auto updates on any of our production systems, or even dev/test ones. I check for new updates, test them and install manually when needed.
As for auto reboots... no. Always manual barring unexpected outages.

hippy
Posts: 5770
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspbian life cycle

Fri Jul 28, 2017 10:51 am

PeterO wrote:
Thu Jul 27, 2017 9:53 pm
Have you ever run a "mission critical system" ? Anyone who does this for real for a living would never have an automated update process installing updates onto running, live systems.
Indeed; but isn't this exactly the problem here, the Catch-22 ?

Keeping a system up to date non-manually requires using automated means, but automated updating should not be done.

Is the answer therefore that there is no recommended way to keep a system up to date than to ensure it is kept up to date manually ?

Which, for the OP, means that if they want to keep their Pi's up to date to comply with the rules they are under, they will need to regulary check that they are up to date, then manually bring them up to date if they are not. They will need a regime to do this properly.

User avatar
PeterO
Posts: 4942
Joined: Sun Jul 22, 2012 4:14 pm

Re: Raspbian life cycle

Fri Jul 28, 2017 12:00 pm

The point is that if you want to run mission critical systems you need to put the resources in to processes that ensure updates are not going to break your systems. The normal way to do this is as I described earlier.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23338
Joined: Sat Jul 30, 2011 7:41 pm

Re: Raspbian life cycle

Fri Jul 28, 2017 2:04 pm

hippy wrote:
Fri Jul 28, 2017 10:51 am
PeterO wrote:
Thu Jul 27, 2017 9:53 pm
Have you ever run a "mission critical system" ? Anyone who does this for real for a living would never have an automated update process installing updates onto running, live systems.
Indeed; but isn't this exactly the problem here, the Catch-22 ?

Keeping a system up to date non-manually requires using automated means, but automated updating should not be done.

Is the answer therefore that there is no recommended way to keep a system up to date than to ensure it is kept up to date manually ?

Which, for the OP, means that if they want to keep their Pi's up to date to comply with the rules they are under, they will need to regulary check that they are up to date, then manually bring them up to date if they are not. They will need a regime to do this properly.
Indeed, they will need the correct process in place. This is the cost of using computers, not just the Pi. It's why you have IT departments.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Martin Frezman
Posts: 1020
Joined: Mon Oct 31, 2016 10:05 am

Re: Raspbian life cycle

Fri Jul 28, 2017 2:35 pm

Indeed, they will need the correct process in place. This is the cost of using computers, not just the Pi. It's why you have IT departments.
Of course, it may be the other way around. Things are the way they are because we have IT departments.
If this post appears in the wrong forums category, my apologies.

User avatar
PeterO
Posts: 4942
Joined: Sun Jul 22, 2012 4:14 pm

Re: Raspbian life cycle

Fri Jul 28, 2017 2:41 pm

Martin Frezman wrote:
Fri Jul 28, 2017 2:35 pm
Of course, it may be the other way around. Things are the way they are because we have IT departments.
But in this case it isn't.
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

Heater
Posts: 13087
Joined: Tue Jul 17, 2012 3:02 pm

Re: Raspbian life cycle

Fri Jul 28, 2017 3:10 pm

JohnBeardmore,

"All access must be audited by the OS on each individual box"

You will find all logins logged in /var/log/auth.log. Like so:

Code: Select all

Jul 27 19:17:01 jhctech1 CRON[11819]: pam_unix(cron:session): session closed for user root
Jul 27 20:17:01 jhctech1 CRON[11840]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 27 20:17:01 jhctech1 CRON[11840]: pam_unix(cron:session): session closed for user root
Jul 27 21:17:01 jhctech1 CRON[11853]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 27 21:17:01 jhctech1 CRON[11853]: pam_unix(cron:session): session closed for user root
Jul 27 21:18:43 jhctech1 su[11861]: Successful su for root by dataplicity
Jul 27 21:18:43 jhctech1 su[11861]: + /dev/pts/4 dataplicity:root
Jul 27 21:18:43 jhctech1 su[11861]: pam_unix(su:session): session opened for user root by (uid=1002)
Jul 27 21:18:43 jhctech1 systemd-logind[509]: New session c1 of user root.
Jul 27 21:18:43 jhctech1 systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)
Of course if anyone can get root access to your Pi they can remove whatever they like from that log.

"Remote access will again be via the University VPN initially using a named ... account".

Meh.

"OS on the Pi boxes must be kept updated and patched at all times, and the OS itself must be current and within support lifecycle"

Best to roll your own OS. Perhaps based on Raspbian. Then you get to dictate the patches, updates and life cycle.

"Any out-of-date OS with any known vulnerabilities connected to the University network may be disconnected without notice". ...... this action would disable the heating controls in seven buildings and a small district heating network, and knock a students PhD project on the head."

Ah, now I see the problem.

You have a mission critical system. I would call a district heating network and years of PhD work a critical mission. BUT you are running it of an un-trusted network that can be pulled out from under you at any time. Those admins are your attackers that can DOS you at a whim.

Really, you should create a network that you can trust and control yourself. Perhaps with your own WiFi access points. Perhaps using cellular connectivity.

Now a days you can even use alternative wireless technologies. For example LoRa http://www.semtech.com/wireless-rf/inte ... t-is-lora/.

LoRa would suite if you are monitoring/controlling systems up to some kilometers away and don't need huge bandwidth.

User avatar
JohnBeardmore
Posts: 211
Joined: Thu Nov 15, 2012 11:03 pm
Location: Derbyshire UK.
Contact: Website

Re: Raspbian life cycle

Sat Jul 29, 2017 12:28 am

Martin:
The other reason for using Raspbian is that if you’re writing an open source thing, you want to develop and distribute it on the platform with the most users which has always predisposed me to Raspbian.
Ubuntu LTS does seem to be supported for Pis. I’ve not looked into it much, but see for example https://insights.ubuntu.com/2016/06/20/ ... -the-rpi2/ - it exists at least. I’ve not had much exposure to Ubuntu for a long time, and it never inspired me. I wouldn’t want to swap to it without good reason.

Heater:
I’d love to build a distribution from scratch, but almost nobody has that sort of spare time, and I suppose the whole idea of the open source movement is that you don’t generally have to.
We do customise Raspbian quite a bit though. Each time I do this it takes quite a few evenings of faffing about.
The Docker idea is an interesting one, but the sort of thing I’ve fallen foul of before is no longer being able to use inittab to launch demons. I doubt Docker would protect you against that sort of change, and presumably it can’t do much if different kernels are needed ?

Runboy93
:) Yes !

Dougie:
Agreee completely. This goes beyond implementing a safe system. This is about policy as much as need.
Pinet looks interesting as a tool for maintaining herds of Pis. Do you know if it’s free / open source ?

Bensimmo:
They aren’t asking for physical security, but the Pis will live in boxes full of mains wiring and relays with big yellow ‘Danger 230 Volt’ stickers on the front. Hopefully this will discourage the casually curious.
An apt-get security-update option would be nice !
Who are the Integrator team ?

Jamesh:
There is a difference between testing a new OS release, and testing all possible interactions with previous use of the OS. When they changed init to something that no longer read inittab, I’ve no doubt they tested it, but it would still break the way I was starting our various demons. Martin has explained it better than me.

PeterO:
Agreed, though it seems that IT support people who have grown up in ‘world of windows’ expect a constant stream of upgrades, necessary or not, and trust Microsoft to apply them.

Jamesh:
Yes, we have IT departments to do this sort of thing. Unfortunately it is they who are making the rule that it’s our problem.

Heater:
Yes, I had thought about LoRa, but timescales are tight, budgets are small, and the system already works over IP.

Thanks all ! J/.
Author of oBeMS open source Building energy Management System.
Automatic Meter Reading (AMR), Building Management System (BMS),
Building Energy Management System (BEMS), Infrastructure Control System (ICS).
See: http://t4sustainability.co.uk/oBeMS/

User avatar
JohnBeardmore
Posts: 211
Joined: Thu Nov 15, 2012 11:03 pm
Location: Derbyshire UK.
Contact: Website

Re: Raspbian life cycle

Sat Jul 29, 2017 12:47 am

My preferred approach I suspect, will be to keep upgrading Jessie until it stops being supported with security patches. So can the RPF give any indication of how long this is likely to be ?

Many thanks, J/.
Author of oBeMS open source Building energy Management System.
Automatic Meter Reading (AMR), Building Management System (BMS),
Building Energy Management System (BEMS), Infrastructure Control System (ICS).
See: http://t4sustainability.co.uk/oBeMS/

Return to “Raspbian”