There's many hours of reading the Debian CTTE and bug archives about the system init discussion if you have a bit of time and are that interested.
A short version, which is mostly still applicable and accurate for the large part from the past 2 years, is the Debian debate wiki pages with the arguments for and against various init systems to switch to. It's notable that *no-one* wanted to use sysvinit moving into Jessie, and the votes for upstart were heavily partisan being current and ex-canonical employees or upstart developers... those without that specific background preferred to switch to systemd. The other semi-serious candidate was openrc but it had poor documentation at the time and wasn't even in the debian archives at the point the discussions started. It was also seen as only a slightly incremental improvement over sysvinit/insserv and not worth the effort of a major modernisation of init... if everything was going to shift then it needed capabilities like socket activation etc which left upstart or systemd as contenders.
It's OK to continue using those conventional, non-systemd services, and Debian at least (don't know about other distros) generally does so.
Heck Fedora, which is usually portrayed as the Lennart playground for systemd because "Red Hat" doesn't even use -networkd, -resolved or -timed instead preferring NetworkManager, <none> (there's been debate about unbound as a caching daemon in the past but they didn't go anywhere), and chrony for those roles.
You can also just pop something in/etc/rc.d/rc.local and mark it executable on most distributions... But of course then you lose the benefit of a dedicated unit in journald for your script to log in and can't test it via a simple systemctl start
This assumes a script that you want to run to completion and exit to be considered complete... otherwise you may want a different type (man systemd.service for full details).
If the script is going to kick off any processes you want to hang around beyond the lifetime of the script then add RemainAfterExit=yes
Add any Requires dependency statements or After/Before for ordering direction if that needs to be tuned (man systemd.unit) but otherwise this will be run as soon as multi-user.target is reached.
That's not exactly true... that 's only if you specifically pay for the Extended Lifecycle Support subscription (which incidentally still supports RHEL4)...
Without that specific extra subscription RHEL5 goes EOL March 2017... and CentOS5 will get the last of its updates then as they don't get and rebuild the ELS packages.
If you install it you'll see you get a 'Core' Ubuntu system in/snap/something-or-other and then overlayed on that is the snap in/snap/app-of-some-kind
So basically they use a not-quite-namespace (pivot-root to be precise) with no container tech to do a "super chroot" (via pivot-root) into an minimal Ubuntu installation to run the app overlayed on that...
In theory AppArmor... except confinement only works under Mir...
And as for the cross distro stuff in the PR statement? The Arch build disables the confinement tech (since it's a Canonical special and not upstreamed) and the Fedora COPR in addition to that only "works" with selinux not enforcing.
Snapd seems to be spreading with the same wildfire potential that systemd did.
Not really... it was pushed to AUR which anyone can do and is in COPR like anyone can do.
No one from the Fedora side has worked on this, the Canonical employee who has that COPR is not a Fedora packager and the various desktop communities have been coordinating on Flatpak
I'd strongly suggest never taking a Canonical Press Release at face value given the recent history with them...
THAT'S EXACTLY THE POINT. Need something/sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat,... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.
The problem is that this results in race conditions and "who watches the watchdog" type of scenarios. Plus if the intermediate supervisor dies for some reason the children with then be reparented to PID1, ie the basic simple init, and the restarted supervisor would then lose sight of them properly (ie no longer a parent so can't wait() on them).
Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision
Note quite. Fedora is not the upstream for systemd, systemd is its own upstream and frankly has been driven more by CoreOS needs than Fedora ones recently (with the whole resolved and networkd stuff which are not used in Fedora since we use NetworkManager). Check the number of patches in the F24 spec for instance. The discussion is ongoing at the moment and this will become a F25 change that gets debated by FESCO. It's likely that the Server and Workstation product, for instance, may split in their behaviours here given the different use cases.
systemd was and is a power grab, plain and simple
No it is an attempt to fix our broken init landscape (it's notable that no one wanted to keep sysvinit as the default in the Debian CTTE decision) and solved not only the sysvinit problems but the upstart ones as well.
Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem.
Fedora is a well integrated distribution with a set scope of things supported clearly defined. Just as we don't support a BSD kernel the fundamental frameworks are made clear so that the stuff packaged can be well tested against that base.
People who didn't want to use systemd absolutely were being subjected to it against our will. To claim otherwise is ludicrous.
You are entirely free to use Slackware, Gentoo, Debian, Devuan or any other non-systemd distro you wish. It's notable that Arch and Suse switched to systemd of their own free will and neither are downstream of Fedora or subject to decisions there.
Note that systemd-230 has only just been released so it's only arrived in Rawhide.
Fedora 24 will still ship with systemd-229
You can switch to this behaviour by changing your logind.conf on F23 or F24 but obviously that won't entirely act as systemd-230 since it won't have the same code path.
The question has been raised about this being adopted in F25 and no doubt FESCO will have to make a decision as a system wide change.
There is a reasonable likelihood this default behaviour in Fedora will be rejected - or at least only in the Workstation product with the Server product maintaining the old behaviour.
You're using pkill but then grepping the result of ps for the state of the while loop?
while pgrep sco &>/dev/null do
pkill -9 sco done
Of course that will only kill sco once as as soon as no sco is in the process table the while loop will exit... given how sco behaves though perhaps we should do:
while true do
if pgrep sco &>/dev/null
then
pkill -9 sco
fi sleep 1 done
(Do you think Oracle will ever let MySQL grow so it can challenge Oracle's flagship product?)
This is where MariaDB comes in of course and unless you really love Oracle the only sane thing to do these days is to use that instead if you *need* MySQL...
Local user arbitrary code execution when opening a specially crafted document (via the HWP filter, document can have any extension to disguise it a bit).
CVE disclosed in April 2015 with LibreOffice having a fix out the same month (within a week tops of disclosure)...
Apache OpenOffice is still exploitable at the present time with 4.1.2 due to fix the bug (by removing the HWP filter entirely as opposed to fixing the filter)... but they've been struggling to get this built and released for months at this point.
So back when Sun maintained OpenOffice.org and sold StarOffice they had a Contributor License Agreement that required handing over ownership of patches to them so they could sell the closed source supported suite and license out to IBM for Symphony.
To get around this bureaucracy and to not sign over ownership for patches most distributions used go-oo.org (aka ooo-build) that was the source code of OpenOffice.org with a bunch of patches on top to help compatibility with MS Office and some other things that Sun could or did not want in the upstream oo.org code.
When Oracle bought Sun they left oo.org languishing with no maintenance for months. This was naturally unacceptable to the various linux distros and they didn't want to be beholden to Oracle's whims (for good reason given the state of the various projects that used to be with Sun). Due to this they got together and formed The Document Foundation and took the go-oo.org code (which was basically what this group used and collaborated on anyway) and forked it to LibreOffice.
Fast forward some more time and Oracle decide they don't want anything to do with OpenOffice.org after all and essentially (with IBM's help... presumably so there would be a sort of maintained base for Symphony) dumped it on the Apache Software Foundation. As per their requirements it went through an incubation process and all the code was relicensed to the Apache Public License. This was months after LibreOffice had been created and worked on and most consider it a pretty petty move rather than giving the brand to TDF to work with.
From that point on it's pretty much been IBM driving Apache OpenOffice (as they renamed oo.org to) although they appear to have stopped caring about it mid to end last year. The amount of development work on AOO is minimal compared to LO and the number of active committers is in the teens (at best) for AOO compared to the hundreds for LO.
Due to the way the licensing works out LO can merge in any fixes (there were some in the early days, not many now as can be seen in the CVE issue I mentioned) but AOO cannot merge in work from LO.
The last release of AOO was August 2014 and if you go look at the changelogs from 3.4 (the first AOO release as opposed to oo.org IIRC... mostly rebranding) up to the 4.1.1 then you'll see there's been minimal work - mostly translations. Anything developed/fixed in AOO is either merged into LO or improved/obsoleted by other work. Compare these to the release notes for each LO release from the forking point of 3.3 and it really is quite significant - the heavy work on clean up and better build systems for LO lower the barrier to entry for LO contribution by the common person too.
To give an idea how bad this has got the no-interaction code execution as privileges of user bug by a special HWP file was announced publicly last April. It was fixed in LibreOffice the same month and users would have had the update notification and been protected. Anyone using Apache OpenOffice is still vulnerable and although there was a disclosure on the security part of the AOO site at the time, the workaround was to 'delete.dll/.so'... not a release with a fix and unless anyone actively went to check up on this they would not have known the issue.
To add to this (if it's not enough already) AOO can still only read and not write docx/xlsx/pptx (OOXML) files produced by MS Office whereas LibreOffice can
The likelihood is that they have Software Assurance anyway so are covered for whatever version of MS Office they choose to run on whatever version of Windows they want to support.
If the IS staff deem an upgrade required there will be a time/people cost of sorts (although remember the staff will be employed doing X anyway so it's more a scheduling priority) but not an licensing upgrade cost.
It genuinely was down at one point yesterday (around 7pm BST onwards... not sure when it was usable again).
I couldn't even log into the uplay website much less authenticate my game. Interestingly it was partially working as it would try to authenticate and then the uplay application would crash - I assume with some sort of null pointer error... although I didn't bother to debug it.
Since I had already started it once earlier in the day though before uplay services took a nose dive disabling my network interface allowed me to start uplay in offline mode (I could then re-enable the interface after choosing offline) and play the game fine - just without the multiplayer features.
Slashdot Mirror
There's many hours of reading the Debian CTTE and bug archives about the system init discussion if you have a bit of time and are that interested.
A short version, which is mostly still applicable and accurate for the large part from the past 2 years, is the Debian debate wiki pages with the arguments for and against various init systems to switch to. It's notable that *no-one* wanted to use sysvinit moving into Jessie, and the votes for upstart were heavily partisan being current and ex-canonical employees or upstart developers ... those without that specific background preferred to switch to systemd. The other semi-serious candidate was openrc but it had poor documentation at the time and wasn't even in the debian archives at the point the discussions started. It was also seen as only a slightly incremental improvement over sysvinit/insserv and not worth the effort of a major modernisation of init ... if everything was going to shift then it needed capabilities like socket activation etc which left upstart or systemd as contenders.
The debian init debate points
The bug for the default init for the CTTE to decide"
It's OK to continue using those conventional, non-systemd services, and Debian at least (don't know about other distros) generally does so.
Heck Fedora, which is usually portrayed as the Lennart playground for systemd because "Red Hat" doesn't even use -networkd, -resolved or -timed instead preferring NetworkManager, <none> (there's been debate about unbound as a caching daemon in the past but they didn't go anywhere), and chrony for those roles.
You can also just pop something in /etc/rc.d/rc.local and mark it executable on most distributions... But of course then you lose the benefit of a dedicated unit in journald for your script to log in and can't test it via a simple systemctl start
Err systemd and firewalld have nothing to do with each other
I suggest you do a modicum of research next time before spewing such obvious bullshit
This assumes a script that you want to run to completion and exit to be considered complete... otherwise you may want a different type (man systemd.service for full details).
If the script is going to kick off any processes you want to hang around beyond the lifetime of the script then add RemainAfterExit=yes
Add any Requires dependency statements or After/Before for ordering direction if that needs to be tuned (man systemd.unit) but otherwise this will be run as soon as multi-user.target is reached.
My laptop is an Intel Skylake integrated GPU and Nvidia GTX 960m discrete GPU.
Running Fedora 25 and nouveau works fine using PRIME to select whether something should run on the Intel or the Nvidia chip.
That's not exactly true ... that 's only if you specifically pay for the Extended Lifecycle Support subscription (which incidentally still supports RHEL4) ...
Red Hat Support Policy
Without that specific extra subscription RHEL5 goes EOL March 2017... and CentOS5 will get the last of its updates then as they don't get and rebuild the ELS packages.
Not /opt ... /snap actually ...
If you install it you'll see you get a 'Core' Ubuntu system in /snap/something-or-other and then overlayed on that is the snap in /snap/app-of-some-kind
So basically they use a not-quite-namespace (pivot-root to be precise) with no container tech to do a "super chroot" (via pivot-root) into an minimal Ubuntu installation to run the app overlayed on that ...
In theory AppArmor ... except confinement only works under Mir ...
And as for the cross distro stuff in the PR statement? The Arch build disables the confinement tech (since it's a Canonical special and not upstreamed) and the Fedora COPR in addition to that only "works" with selinux not enforcing.
Not really ... it was pushed to AUR which anyone can do and is in COPR like anyone can do.
No one from the Fedora side has worked on this, the Canonical employee who has that COPR is not a Fedora packager and the various desktop communities have been coordinating on Flatpak
I'd strongly suggest never taking a Canonical Press Release at face value given the recent history with them...
The problem is that this results in race conditions and "who watches the watchdog" type of scenarios. Plus if the intermediate supervisor dies for some reason the children with then be reparented to PID1, ie the basic simple init, and the restarted supervisor would then lose sight of them properly (ie no longer a parent so can't wait() on them).
Note quite. Fedora is not the upstream for systemd, systemd is its own upstream and frankly has been driven more by CoreOS needs than Fedora ones recently (with the whole resolved and networkd stuff which are not used in Fedora since we use NetworkManager). Check the number of patches in the F24 spec for instance. The discussion is ongoing at the moment and this will become a F25 change that gets debated by FESCO. It's likely that the Server and Workstation product, for instance, may split in their behaviours here given the different use cases.
No it is an attempt to fix our broken init landscape (it's notable that no one wanted to keep sysvinit as the default in the Debian CTTE decision) and solved not only the sysvinit problems but the upstart ones as well.
Fedora is a well integrated distribution with a set scope of things supported clearly defined. Just as we don't support a BSD kernel the fundamental frameworks are made clear so that the stuff packaged can be well tested against that base.
You are entirely free to use Slackware, Gentoo, Debian, Devuan or any other non-systemd distro you wish. It's notable that Arch and Suse switched to systemd of their own free will and neither are downstream of Fedora or subject to decisions there.
Note that systemd-230 has only just been released so it's only arrived in Rawhide.
Fedora 24 will still ship with systemd-229
You can switch to this behaviour by changing your logind.conf on F23 or F24 but obviously that won't entirely act as systemd-230 since it won't have the same code path.
The question has been raised about this being adopted in F25 and no doubt FESCO will have to make a decision as a system wide change.
There is a reasonable likelihood this default behaviour in Fedora will be rejected - or at least only in the Workstation product with the Server product maintaining the old behaviour.
No it doesn't, it uses BTRFS for /home
Similar in capabilities (subvolumes, snapshots, COW, etc) but very different tech in implementation.
or just use pgrep ...
You're using pkill but then grepping the result of ps for the state of the while loop?
while pgrep sco &> /dev/null
do
pkill -9 sco
done
Of course that will only kill sco once as as soon as no sco is in the process table the while loop will exit ... given how sco behaves though perhaps we should do:
while true /dev/null
do
if pgrep sco &>
then
pkill -9 sco
fi
sleep 1
done
Recently I put in a bug report for AOO and after a few months they had a fix incorporated into a new release. It seems like there is still life there.
Link to bug ID? I question your value of 'recent' given there hasn't been an Apache OpenOffice release since August 2014 ...
Local user arbitrary code execution when opening a specially crafted document (via the HWP filter, document can have any extension to disguise it a bit).
CVE disclosed in April 2015 with LibreOffice having a fix out the same month (within a week tops of disclosure) ...
Apache OpenOffice is still exploitable at the present time with 4.1.2 due to fix the bug (by removing the HWP filter entirely as opposed to fixing the filter) ... but they've been struggling to get this built and released for months at this point.
I wrote about this on reddit only recently ...
Link to the discussion there
Copied in full to here:
So back when Sun maintained OpenOffice.org and sold StarOffice they had a Contributor License Agreement that required handing over ownership of patches to them so they could sell the closed source supported suite and license out to IBM for Symphony.
To get around this bureaucracy and to not sign over ownership for patches most distributions used go-oo.org (aka ooo-build) that was the source code of OpenOffice.org with a bunch of patches on top to help compatibility with MS Office and some other things that Sun could or did not want in the upstream oo.org code.
When Oracle bought Sun they left oo.org languishing with no maintenance for months. This was naturally unacceptable to the various linux distros and they didn't want to be beholden to Oracle's whims (for good reason given the state of the various projects that used to be with Sun). Due to this they got together and formed The Document Foundation and took the go-oo.org code (which was basically what this group used and collaborated on anyway) and forked it to LibreOffice.
Fast forward some more time and Oracle decide they don't want anything to do with OpenOffice.org after all and essentially (with IBM's help ... presumably so there would be a sort of maintained base for Symphony) dumped it on the Apache Software Foundation. As per their requirements it went through an incubation process and all the code was relicensed to the Apache Public License. This was months after LibreOffice had been created and worked on and most consider it a pretty petty move rather than giving the brand to TDF to work with.
From that point on it's pretty much been IBM driving Apache OpenOffice (as they renamed oo.org to) although they appear to have stopped caring about it mid to end last year. The amount of development work on AOO is minimal compared to LO and the number of active committers is in the teens (at best) for AOO compared to the hundreds for LO.
Due to the way the licensing works out LO can merge in any fixes (there were some in the early days, not many now as can be seen in the CVE issue I mentioned) but AOO cannot merge in work from LO.
The last release of AOO was August 2014 and if you go look at the changelogs from 3.4 (the first AOO release as opposed to oo.org IIRC... mostly rebranding) up to the 4.1.1 then you'll see there's been minimal work - mostly translations. Anything developed/fixed in AOO is either merged into LO or improved/obsoleted by other work. Compare these to the release notes for each LO release from the forking point of 3.3 and it really is quite significant - the heavy work on clean up and better build systems for LO lower the barrier to entry for LO contribution by the common person too.
The proposed AOO release of 4.1.2 is going forwards at the moment - driven mostly by only a few people Apache OpenOffice Dev mail archives.
To give an idea how bad this has got the no-interaction code execution as privileges of user bug by a special HWP file was announced publicly last April. It was fixed in LibreOffice the same month and users would have had the update notification and been protected. Anyone using Apache OpenOffice is still vulnerable and although there was a disclosure on the security part of the AOO site at the time, the workaround was to 'delete .dll/.so' ... not a release with a fix and unless anyone actively went to check up on this they would not have known the issue.
To add to this (if it's not enough already) AOO can still only read and not write docx/xlsx/pptx (OOXML) files produced by MS Office whereas LibreOffice can
Not only that but OpenWRT does not support it at this time.
Forum discussion where openwrt devs say not to buy this.
Openwrt hardware compatibility page for this model
The likelihood is that they have Software Assurance anyway so are covered for whatever version of MS Office they choose to run on whatever version of Windows they want to support.
If the IS staff deem an upgrade required there will be a time/people cost of sorts (although remember the staff will be employed doing X anyway so it's more a scheduling priority) but not an licensing upgrade cost.
It genuinely was down at one point yesterday (around 7pm BST onwards... not sure when it was usable again).
I couldn't even log into the uplay website much less authenticate my game. Interestingly it was partially working as it would try to authenticate and then the uplay application would crash - I assume with some sort of null pointer error ... although I didn't bother to debug it.
Since I had already started it once earlier in the day though before uplay services took a nose dive disabling my network interface allowed me to start uplay in offline mode (I could then re-enable the interface after choosing offline) and play the game fine - just without the multiplayer features.
Following this 'anonymous developer' this article ended up being refuted by multiple developers ...
More bad blood and FUD by EA perhaps?
See more details here and here.
Well when Oracle published and were pushing this it didn't exactly foster good feelings:
http://linux.oracle.com/switch/centos/
One of the most interesting bits of the announcement for me is the deprecation (and future removal) of the SRPMS at ftp.redhat.com ...
Instead the sources will be provided directly at git.centos.org ...
That could have very interesting implications on SciLi/OEL...