[opensuse-factory] [12.1] massive data loss in /var/tmp/
Apparently, 12.1 has added /var/tmp/ to TMP_DIRS_TO_CLEAR in /etc/sysconfig/cron. I was quite surprised when I found out today that I've lost a few GB of data, which used to be safe there. Needless to say that I'm not pleased. No backups, because it wasn't *that* important, but I find such changes without warning suboptimal, to put it politely. m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
so... you expected... something in /var/tmp to be safe? I think it is simple to see the fallacy... Alin -- Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 19 November 2011 12:47:15 Alin Marin Elena wrote:
so... you expected... something in /var/tmp to be safe? I think it is simple to see the fallacy...
The key parts are "used to be safe" and "without warning". A responsible distributor doesn't risk his users' data in this way. m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Melchior FRANZ <melchior.franz@gmail.com> [11-19-11 08:15]:
conversly, a "responsible user" doesn't store data "expecting it to be save" in a system temporary directory, keyword *temporary*: Temporary \Tem"po*ra*ry\, a. [L. temporarius, fr. tempus, temporis, time: cf. F. temporaire.] Lasting for a time only; existing or continuing for a limited time; not permanent; as, the patient has obtained temporary relief. [1913 Webster] -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Melchior FRANZ <melchior.franz@gmail.com> [11-19-11 08:15]:
conversly, a "responsible user" doesn't store data "expecting it to be save" in a system temporary directory, keyword *temporary*: Temporary \Tem"po*ra*ry\, a. [L. temporarius, fr. tempus, temporis, time: cf. F. temporaire.] Lasting for a time only; existing or continuing for a limited time; not permanent; as, the patient has obtained temporary relief. [1913 Webster] ps: default settings on *my_box* do not include /var/tmp so you have made a change or have a local system problem..... -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 19 November 2011 09:03:57 Patrick Shanahan wrote:
ps: default settings on *my_box* do not include /var/tmp so you have made a change or have a local system problem.....
OK, thanks. I've occasionally put stuff under /var/tmp/$USER/ when I intended to throw it away shortly thereafter. Sometimes I kept it for longer, though. This has worked for years, so I don't think I've ever allowed openSUSE to clean out my /var/tmp/. This has happened for the first time now. To the apologists: I don't need lessons about what temporary means. It's just that until recently *I* was the one who decided how long "temporary" lasted. And I've never authorized anyone to delete my data. It's a matter of trust. Unjustified trust, as I know now. Won't make this mistake again. m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Melchior FRANZ schrieb:
I've occasionally put stuff under /var/tmp/$USER/ when I intended to throw it away shortly thereafter. Sometimes I kept it for longer, though.
I'm using ~/temp for that, which I think is way more reasonable than expecting anything in /tmp or /var/tmp to survive for any time. Robert Kaiser -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2011-11-19 at 09:03 -0500, Patrick Shanahan wrote:
And, "a responsible user" makes backup's & test if restore is functioning satisfactory. period. Specially before doing anything drastic. Even then shit happens: Made regularly backups on two different external drives, and tested them, but in my darkest hour they both failed... Who ever you blame, the distributor shouldn't be part of the equation. hw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 19/11/11 12:13, Hans Witvliet wrote:
Who ever you blame, the distributor shouldn't be part of the equation.
Yeah, like the stickers some public transport buses used to have here: "If you are late, it isn't the fault of the driver" :-) Maybe the user has the "tmpwatch" package installed.. ? that's gonna delete files in /var/tmp if they are older than 30 days. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 19 November 2011 13:11:43 Cristian Rodríguez wrote:
Maybe the user has the "tmpwatch" package installed.. ? that's gonna delete files in /var/tmp if they are older than 30 days.
No, he hasn't. In case someone hasn't understood yet: I'm not disputing whether it's a good idea to clean out /var/tmp/ -- it possibly is --, what annoys me is a sudden change in behaviour that kills data without warning, even if they might have been in the wrong place (which isn't such a clear case). But I accept that this isn't default in 12.1 and must come from somewhere else. I also have my ~/tmp/ since years. Still, I considered stuff in /var/tmp/ to be maintained by the applications which put it there. And if $USER put stuff in /var/tmp/$USER/ then I assumed that it would be $USER's responsibility to clean it, whenever s/he feels like it. Temporary doesn't necessarily mean "short-lived". If data is important enough that it should survive rebooting, then it shouldn't be treated as trash by the system. m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le 19/11/2011 19:25, Roger Luedecke a écrit :
it was said very often that /tmp was copied in tmpfs (if I understood well, not sure) and most work done there. I don't know how much it's related to the present problem jdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 19/11/11 15:35, jdd wrote:
It is unrelated to this topic and /tmp is no longer a directory that resides in your hard disk, but in shared memory, if you are running out of memory, it will be put in swap. there is nothing you have to be worried or configure, the kernel will do the work for you. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
---- [*ouch*....that hurts.] I don't have hmmm, actually I do have gigabytes hmmm... I was gonna complain because I use /tmp to tranfer tars of user dirs that can be (under pathological cases) up to 20-30GB, but USUALLY are <5GB (they are roaming profiles, so I prefer to keep them under 2-3GB)... And for a second I thought those were 'large' files...and to have them consume memory and swap.....but then ...I realized, I'm in 2011, not 199x. *sigh*...Actually, wait-- it STILL could be a problem... Still... 2-3 GB can be large -- photoshop had a cow with a 2.6GB tif this morning -- thought I was 'hosed'...couldn't open it for the longest time...(some layer had been 'distorted' and as a result grew to enormous proportions -- thought it wasn't visible as it was contained in a small ~100px mask....the layer had been a pouring of a paintbucket... Photoshop stores such things as bitmasks...it started as a 4.5Kx4.5K image, so each such "fill layer" (in quotes, cuz there is an official fill layer type, that if chosen, won't create the bit mask, but it's not the default, and it's not an option in the default new-layer dialog). So when it got resized -- apparently via 'perspective', instead of distort, a small shift at one end made the other end VERY large... from the size increase, (1.1G added, and PS gets about 75% compression on a unicolor layer, , it added about 4.4G of pixels, or apparently blew up my 'solid black color for my 100px^2 shape to a 69,000px^2 32 bit/px, image. Oddly, it just hung, trying to open (disk trashing with PS's TMP files...as it self monitors physmem usage and then does it's own spill's to tmp. Had 11G free and 0 swap usage (on an SSD). Hmmm... Right now, for a 1.5G image, PS is using 163GB in /tmp (actually a per-user tmp)....and THAT actually would be a problem if it was on a tmpfs... as I don't have SWAP configged at 4-8X available memory. May not be an issue...BUT..that had been done on windows, I'd be screwed. To edit images I have to keep almost half my hard disk free for Adobe Photoshop 5 -- unbelievable. What a Frickin pig! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2011-11-19 at 16:18 -0300, Cristian Rodríguez wrote:
Many people do not have big swaps. Fortunately, what you say doesn't seem to be true: Elanor:~ # mount | grep tmp devtmpfs on /dev type devtmpfs (rw,relatime,size=372396k,nr_inodes=93099,mode=755) tmpfs on /dev/shm type tmpfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,relatime,mode=755) tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755) I don't see why /media has to be a tmpfs either. It is used for automounting. Are any of these optional? They are not listed in fstab. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7IQK8ACgkQtTMYHG2NR9WVsACcDHMybMA/Nch6/EGSOVsxWjd6 gk4An28ANWIIPoO0vMDaZ8TeKd4XzmfW =uVNr -----END PGP SIGNATURE-----
On Sunday 20 November 2011, Carlos E. R. wrote:
If /tmp became tmpfs then this happens hopefully only whith fresh installtion and not after zypper dup!?
What's this? /var/run?
/media is made to hold only auto created dirs for auto mounting. Making it tmpfs might be an elegant way to get it cleared every reboot without needing scripts to do that. In opposite to /tmp it will not eat much swap space. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 19/11/11 21:08, Rüdiger Meier wrote:
What's this? /var/run?
Explained in detail here http://lwn.net/Articles/436012/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 20 November 2011, Cristian Rodríguez wrote:
Ok, so hopefully it's only a systemd issue. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 19/11/11 23:03, Rüdiger Meier wrote:
No, it is a permanent change for all early boot applications, some have not been updated yet though. and for the people asking, yes, I am wrong, /tmp in tmpfs requires user explicit configuration, it is not a default. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LNX.2.00.1111210048420.6471@Telcontar.valinor> On Sunday, 2011-11-20 at 01:08 +0100, Rüdiger Meier wrote:
On Sunday 20 November 2011, Carlos E. R. wrote:
If /tmp became tmpfs then this happens hopefully only whith fresh installtion and not after zypper dup!?
My only test install is fresh, and virtual.
That's a different one. There is now a /run, and in my test system it is populated: Filesystem Size Used Avail Use% Mounted on rootfs 9.9G 3.4G 6.1G 36% / devtmpfs 364M 36K 364M 1% /dev tmpfs 370M 0 370M 0% /dev/shm tmpfs 370M 572K 370M 1% /run /dev/sda2 9.9G 3.4G 6.1G 36% / tmpfs 370M 0 370M 0% /sys/fs/cgroup tmpfs 370M 572K 370M 1% /var/run tmpfs 370M 0 370M 0% /media tmpfs 370M 572K 370M 1% /var/lock Having those 370M (I hope shared between all of them) it is an issue for me, because this test system is a virtual machine on VMplayer, with only "756944k" of RAM. Both /run and /var/run are different filesystems, but they contain the same files, as far as I can see. Ahhh... The link Cristian posted explains it. A bind mount. They propose to make symlinks later on.
But I don't see why it is needed. Are there that many mounts per minute so that we need to run the /media on ram? - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7JkvIACgkQtTMYHG2NR9V5JwCgk7zhAEiKO5/o5rnXk+AiETci nfUAnRs/NWmIVe+8vHzM092KKuuyC8IK =IoJP -----END PGP SIGNATURE-----
On 20/11/11 20:53, Carlos E. R. wrote:
No, it is not. it is the default tmpfs size, (half of your ram not counting swap) that space IS NOT reserved, it is a "hint" to the maximum size that can be allocated.
But I don't see why it is needed. Are there that many mounts per minute so that we need to run the /media on ram?
it is to ease software maintenance, and uses no ram since it is empty. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2011-11-20 at 21:17 -0300, Cristian Rodríguez wrote:
On 20/11/11 20:53, Carlos E. R. wrote:
Ah, ok. That's better.
Mmmm... :-) - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7JnukACgkQtTMYHG2NR9VgTwCfVOoWrsw+qnZq/7O9cpyEMpir wk0AoI4G+n+CbJ4N0yEEpIHiCRQAzI// =kHw/ -----END PGP SIGNATURE-----
On 11/20/2011 07:17 PM, Cristian Rodríguez pecked at the keyboard and wrote:
As in easier to use then "zypper up package1"? What is so fubar'd that some other form of package management is now needed? -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LNX.2.00.1111211336400.6471@Telcontar.valinor> On Sunday, 2011-11-20 at 23:19 -0500, Ken Schneider - openSUSE wrote:
We are not talking package management in this thread. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7KRfgACgkQtTMYHG2NR9UUPQCfWHHHPvT4+Dc1oIk2o36zkjag UScAoI+RNiIgA1NfkDYuCesKlAHGWdWH =m9QQ -----END PGP SIGNATURE-----
On 11/21/2011 07:37 AM, Carlos E. R. pecked at the keyboard and wrote:
Sorry for the noise, I guess I just don't understand the logic here. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2011-11-21 at 08:23 -0500, Ken Schneider - openSUSE wrote:
We are not talking package management in this thread.
Sorry for the noise, I guess I just don't understand the logic here.
You probrably got confused with another thread where they are discussing package management. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7KVycACgkQtTMYHG2NR9Xa6wCfeXoOHdJUNejoE6WFRKsetG5x TD4AnAutj7RXwdzAKRwJXUQf2nvTQg0Z =3/D9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Alin Marin Elena wrote:
??? Safe? I'd expect it to be listed in 'long_tmp_dirs_to_clear', consistent with standards going back 20+ years. To move it into 'tmp_dirs_to_clear' is making it the same as "/tmp". If that was desired, they system would never have been designed with two separate tmp dirs. They are supposed to be treated differently. One is short-term tmp storage, the other is longer term tmp storage. I wouldn't expect anything there to be safe forever. But I would expect something in /var/tmp to be there for at least a month on my system. Moving it into the group "tmp_dirs", vs. "long_tmp_dirs", is a DESIGN FLAW. Someone screwed up. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 19 November 2011 12:45, Melchior FRANZ <melchior.franz@gmail.com> wrote:
Apparently, 12.1 has added /var/tmp/ to TMP_DIRS_TO_CLEAR in /etc/sysconfig/cron. I was quite surprised when I found out today
$ cat /etc/os-release NAME=openSUSE VERSION = 12.1 (Asparagus) VERSION_ID="12.1" PRETTY_NAME="openSUSE 12.1 (Asparagus) (x86_64)" ID=opensuse $ grep "^TMP_DIRS_TO_CLEAR" -B7 /etc/sysconfig/cron ## Type: string # # This variable contains a list of directories, in which old files are to # be searched and deleted. The frequency is determined by MAX_DAYS_IN_TMP # # Defaults to /tmp if empty # TMP_DIRS_TO_CLEAR="" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2011-11-19 at 13:30 -0000, Cristian Morales Vega wrote:
MAX_DAYS_IN_TMP="" MAX_DAYS_IN_LONG_TMP="" The second one applies to /var/tmp/, and is disabled by default. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7Hv5QACgkQtTMYHG2NR9U/ggCbBWS5hwsBszwxLEbPMPcFWGe+ NEoAn33gSTiDIDTITNjxH1QOu28WNrdr =GYId -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 19 November 2011 13:45:36 Melchior FRANZ wrote:
The Filesystem Hierarchy Standard stipulates that the OS must not delete files in /var/tmp on boot, so if this were the case you would be right. However, I can't see that this is the case on my system. The default setting is /tmp only, and I can't immediately see anything in YaST that would add /var/tmp to it Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2011-11-19 at 15:18 +0100, Anders Johansson wrote:
# This variable contains a list of directories, in which old files are to # be searched and deleted. The frequency is determined by MAX_DAYS_IN_LONG_TMP # If cleaning of /var/tmp is wanted add it here. # LONG_TMP_DIRS_TO_CLEAR="" - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7HwFYACgkQtTMYHG2NR9UmLQCaAmbVqQbf75HHcdvliIVzj+3D dk4Anjrc2wYz6wQZLmhXs/G42y0j73Sr =CKhg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 19 November 2011 15:42:30 Carlos E. R. wrote:
I know, but it is empty by default, and files in my /var/tmp aren't getting deleted on my 12.1 Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2011-11-19 at 15:49 +0100, Anders Johansson wrote:
I know. I wonder what the OP got. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7Hzg4ACgkQtTMYHG2NR9XJHACgkPOfVCh4it0YMr9hR+ZTYKos pBEAniA4TD63yrNP8ADTYAkHL9eZYF8T =ISk/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 19 November 2011 16:40:50 Carlos E. R. wrote:
I know. I wonder what the OP got.
$ grep DIRS_TO_CLEAR= /etc/sysconfig/cron TMP_DIRS_TO_CLEAR="/tmp /var/tmp" LONG_TMP_DIRS_TO_CLEAR="" And I haven't set that. Well, at least not since I can remember. So either something in 12.1 or a recent Tumbleweed upgrade has set it, *or* I've set it several years ago and only since a few days it has an effect, maybe because of a bugfix? Anyway, I'm meanwhile restoring parts from a non-backup ... m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 19 November 2011, Melchior FRANZ wrote:
It would be really interesting to find out if this happend automatically somehow. What was the mtime of /etc/sysconfig/cron? Do you have backup snapshots of /etc/sysconfig? What about /var/adm/backup/sysconfig/? cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Argh ... I hate it when this happens: On Saturday 19 November 2011 17:33:31 Rüdiger Meier wrote:
Do you have backup snapshots of /etc/sysconfig?
Yes. I looked up a more than two year old backup of /etc/sysconfig/cron, and apart from a minor, unrelated change it's exactly the same. I must have added /var/tmp/ myself, then, or it was set in those days. So, openSUSE just does now do what it has been told ages ago. Apparently it hasn't been doing that for a few years, or I would have noticed far earlier. Can't blame openSUSE for fixing bugs. And I definitely don't expect a warning for that. :-) I apologize. m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2011-11-19 at 16:58 +0100, Melchior FRANZ wrote:
I have in my work partition (11.4), updated many times: TMP_DIRS_TO_CLEAR="/tmp" LONG_TMP_DIRS_TO_CLEAR="/var/tmp" In another test partition, was a fresh install: Telcontar:~ # cat /other/test_a2/etc/SuSE-release openSUSE 11.2 (x86_64) VERSION = 11.2 Telcontar:~ # grep DIRS_TO_CLEAR= /other/test_a2/etc/sysconfig/cron TMP_DIRS_TO_CLEAR="/tmp" LONG_TMP_DIRS_TO_CLEAR="" - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7H7eIACgkQtTMYHG2NR9UA9gCgg3+nJ6EPTU5pD/3RAWu3a4QY pFwAmgIfu/9DJUuOUfIYSC8KYZNXMFpA =PBvP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le samedi 19 novembre 2011 à 15:49 +0100, Anders Johansson a écrit :
There is one bug I've just been informed where /etc/init.d/boot.cleanup is now replaced by systemd equivalent, which is not doing exactly the same things as the old script. I'll see how I can fix this (see https://bugzilla.novell.com/show_bug.cgi?id=721682 ) -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 28 November 2011 13:55:47 Frederic Crozat wrote:
Ahh, interesting. Then it *was* an opensuse bug which killed a few GB of my data. Just checked and I've got the "no" there, while the cron mechanism was disabled as well: MAX_DAYS_IN_TMP="" TMP_DIRS_TO_CLEAR="/tmp /var/tmp" CLEAR_TMP_DIRS_AT_BOOTUP="no" m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Melchior FRANZ <melchior.franz@gmail.com> [11-28-11 08:40]:
No, you didn't read/understand the bug-report. It was about files not being cleared, *not* about files being cleared disreguarding settings. It is an openSUSE bug but not related to your loss. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 28 November 2011 10:44:29 Patrick Shanahan wrote:
* Melchior FRANZ <melchior.franz@gmail.com> [11-28-11 08:40]:
Don't worry -- it's just you who didn't understand my message. While I had admitted in an earlier email that my settings had ordered the system to clean out my /var/tmp, this bug report has reminded me to check the CLEAR_TMP_DIRS_AT_BOOTUP entry, so I re-read my cron config file, and there I found that I had disabled the cron job (empty MAX_DAYS_IN_TMP) *and* disallowed cleaning at bootup. So there was no justification for SuSE to remove any of my data, and it must have been a bug after all. Whether it was the same bug that Frederic pointed to is a different matter. I never said it was. Not that it isn't a likely reason. m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Melchior FRANZ wrote:
----------------- I would agree with the above. Traditionally /var/tmp has been in "LONG_TMP_DIRS_TO_CLEAR"... I have them set to 'autoclean at 21 and 42 days', respectively. I think it would be irresponsible and violate normal unix-cleaning standards to treat /var/tmp the same as /tmp. If the desire was to treat them the same, then there would never have been two separate directories in the first place! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/19/2011 7:45 AM, Melchior FRANZ wrote:
The unrequested unpleasant surprise is never excusable, but really, even I have to say you should have known better than to store anything in any place named */tmp/* just because of exactly this day. It's really not an unexpected event. You do know that tmp stands for "temporary" right? That's pretty much the end of the conversation right there, regardless if that dir ever used to be cleaned automatically or not. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2011-11-21 at 14:14 -0500, Brian K. White wrote:
The system is not the exclusive owner of temporary space. People can use it for temporary purposes of their own. The system is free to erase the temporary files it creates, but not the temporary files created by others - - unless the admin explicitly says otherwise. The problem is that the system is unable to keep track of its own temporary files, so it erases all. That must be the decision of the admin, not of the system, ie, the packagers. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7K034ACgkQtTMYHG2NR9WmaACcC8z7V5iVVNdf+NrW5qxMPW5B croAn0gyghkyBdheAoO5AArzQh03dZUW =nkIG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 21 Nov 2011 23:41:02 Carlos E. R. wrote:
No. *People* can, and should, put their own temporary data elsewhere. As you correctly observe the system cannot keep track of all system, service & daemon generated temporary files, so it *must* periodically remove _all_ of the data within to ensure the system stays usable. For this reason alone system temporary directories are an entirely unsuitable location for either users or admins to manually place *anything*. Losing data from a system tmp dir is 100% the fault of the user/admin that placed it there. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2011-11-23 at 10:28 +0100, Graham Anderson wrote:
On Monday 21 Nov 2011 23:41:02 Carlos E. R. wrote:
Where is that mandated?
As you correctly observe the system cannot keep track of all system, service & daemon generated temporary files, so it *must* periodically remove _all_ of
No. Only if the admin says so, and in the manner he says so. And openSUSE defaults to respect this, no temporary files are erased. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7NsC0ACgkQtTMYHG2NR9V3yACgkzxGpp3xcjgpQRpPWDK5XY3V JMQAnieqqY2m3L65oUWYCDUPwWOqMY4z =ESjl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Graham Anderson <graham.anderson@gmail.com> writes:
People *can* put their data elsewhere but they should *not*, or so, is what my admin tells me :) And neither posix nor FHS suggest otherwise.
While `the system' (I assume file system here) doesn't keep track of *why* I put my files there, it certainly keeps track of who did it as per file states, stat(1). Why would any daemon not running in my name produce files in $TMPDIR and friends that belong to me? And any daemon that does run in my name and offloads stuff in $TMPDIR is not the business of some system magic. If dcop fails to clean up after itself (or take any program for that matter) fix that, and don't try to fix the user/admin.
Losing data from a system tmp dir is 100% the fault of the user/admin that placed it there.
Nope. Sebstian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday, November 24, 2011 08:47:49 AM Sebastian Freundt wrote:
This thread has been going on too long. When I was eight or so, I remember my stepdad teaching me some coumputer things. He used DOS, and had access to some sort of *nix via a terminal emulator. One of the first things he told me was "never never put things in a temp area unless you are ready for them to get lost. Temp stands for temporary." -- Roger Luedecke openSUSE Ambassador Ind. Repairs and Consulting **Looking for a C++ etc. mentor*** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Melchior FRANZ wrote:
$ tail -2 /usr/lib/tmpfiles.d/tmp.conf d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d That tells systemd to clear files older than 10 resp 30 days in those directories. systemd does not honor TMP_DIRS_TO_CLEAR. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 23 November 2011, Ludwig Nussel wrote:
systemd is also cron replacement?
That tells systemd to clear files older than 10 resp 30 days in those directories. systemd does not honor TMP_DIRS_TO_CLEAR.
If this is really the default now then it should have been a major point on ReleaseNotes. Since this major change was not announced I would consider it a major bug to be fixed by adding /etc/tmpfiles.d according to what is the default in /etc/sysconfig/cron. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Nov 23, 2011 at 10:02 AM, Ruediger Meier <sweet_f_a@gmx.de> wrote:
Rudi, If you read the whole thread: - The user at some point in the past added /var/tmp to /etc/tmpfiles.d - apparently a bug kept that from being honored, so files just sat there - 12.1 fixed the bug and files disappeared. Overall its bad luck, but it is not a major issue from the release management perspective. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev... The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 23 November 2011, Greg Freemyer wrote:
I've read the whole thread. I know that Ludwig's post has nothing to do with the original problem but he still discovered another bug. Moreover I guess now TMP_DIRS_TO_CLEAR is still used by cron. So now user can't fully rely on any of both files neither /usr/lib/tmpfiles.d/tmp.conf nor /etc/sysconfig/cron. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/11/11 12:02, Ruediger Meier wrote:
Not, yet, but hopefully something is done about it.
really ? since when it is a major point that the system actually deletes temporary files as it should ? The good thing is that systemd allows to use a private,unshared /tmp namespace that daemons can use so this whole story can finally be put to an end. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 23 November 2011, Cristian Rodríguez wrote:
On 23/11/11 12:02, Ruediger Meier wrote:
On Wednesday 23 November 2011, Ludwig Nussel wrote:
The point whether it makes sense to store data on /var/tmp has been discussed endless already in this thread... Why not deleting /tmp every nanosecond per default? I have actively configured all our Desktop machines exactly following the openSUSE documented way how and when to delete my /tmp every reboot and every 60 days and deleting /var/tmp after 300 days but not on reboot. If something else happens then it's a bug. Again about /var/tmp use case: Our users know about our setup and they are politely requested to use /var/tmp for their data if no backup is needed, if they need speed (fast local storage) and if they don't need it shared (NFS). This helps me to safe expense /home and backup storage and safes load on NFS for the more important data. My users usually run data mining stuff producing x TB of data to be used just one time if calculation is finished after some weeks. In case their data would be deleted at random dates then they could restart their process to wait another few weeks. But before doing this they would probably kill me. And yes, backuping all this data would be more expensive than waiting again some weeks to reproduce it. Moreover it would not even possible to backup it in real time. And last but not least backuping this data would probably useless because some of their processes simply can't be continued and has to be re-done completely. This use case perfectly matches to what /var/tmp is supposed to be.
My users are no daemons. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 23 November 2011 13:22:55 Cristian Rodríguez wrote:
The good thing is that systemd allows to use a private,unshared /tmp
You mean unlike that evil sysV init, that completely blocked daemons from using $TMP? Any application that does not respect $TMP is simply broken. This includes systemd Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Nov 23, 2011 at 11:30 AM, Anders Johansson <ajohansson@suse.de> wrote:
Oh, like KDE? KDE ignores $TMP, $TMPDIR. You have to use KDETMPDIR or something. -- Jon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/11/11 14:30, Anders Johansson wrote:
Any application that does not respect $TMP is simply broken. This includes systemd
It is not done by default and neither blocks anything, as I understand this functionality is provided by calling clone(2) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2011-11-23 at 16:02 +0100, Ruediger Meier wrote:
On Wednesday 23 November 2011, Ludwig Nussel wrote:
Indeed.
Yep. Too many changes done without informing the users/admins. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7Nsa8ACgkQtTMYHG2NR9VlfwCfRlbOooWbJ6wRToZV1otz6Rq1 xeMAn16OVUqfklQqCadvIEcXLby5v5Pw =s8RT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Ludwig Nussel <ludwig.nussel@suse.de> [2011-11-23 15:46]:
It is kind of ironic how an old request to adapt a similar policy to the above had been shot down on the feature graveyard and was now introduced through the backdoor without discussion. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Nov 23, 2011 at 03:46:33PM +0100, Ludwig Nussel wrote:
Wait a minute. I just checked on my system upgraded from 11.4 and on my system /usr/lib/tmpfiles.d/tmp.conf also contains these entries. In /etc/sysconfig/cron I have forbidden cleans of /tmp (set to 0 days) and /var/tmp (long tmp is unset). Does the above mean that although I have no .rpmsave or .rpmnew files and no entry in the release notes, the contents of both diretories will be "cleaned up" despite my explicit command to leave them alone? If so, I think an urgent warning need to be issued and the bug should be fixed as quickly as possible. Ciao Joerg -- Joerg Mayer <jmayer@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 24 November 2011, Joerg Mayer wrote:
Yes, looks like a bug, see my other post. I can't confirm it in practice because I have no 12.1 or Factory running. That's why I don't filled a bug report yet. Would be nice if you could confirm it and bug report this. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ludwig Nussel <ludwig.nussel@suse.de> writes:
I'm going to add this to the release notes: https://bugzilla.novell.com/show_bug.cgi?id=735027. The behavior per se is ok, but in the update case, when it does not honor old settings, I consider it as a bug. Are there plans to fix this? And, of course, it would have been a bug, if default sysv/sysconfig and systemd related settings would differ... Do we plan to remove these variables from /etc/sysconfig/cron or will we propagate the values from sysconfig to /usr/lib/tmpfiles.d/tmp.conf? -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 06 décembre 2011 à 10:31 +0100, Karl Eichwalder a écrit :
I'd prefer to have the variables handled by systemd. But since time is a scarce resource, contributed patch would help for this :) -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 06 December 2011, Karl Eichwalder wrote:
Note that /usr/lib/tmpfiles.d/*.conf contains systemd's default config only (should not be edited). Users can change it in /etc/tmpfiles.d/*.conf but AFAIR this direcectory does not exist per default yet. see man tmpfiles.d
And, of course, it would have been a bug, if default sysv/sysconfig and systemd related settings would differ...
If possible I would fix it in 12.1 by adding /etc/tmpfiles.d/* which does nothing else than avoiding conflicts between /etc/sysconfig/cron and /usr/lib/tmpfiles.d/*.conf.
As said in 12.1 it has to be fixed. In Factory I would simply drop the idea of having interchangable sysvinit and systemd. Users should know that using systemd or sysvinit results in completely different behavior. By considering this statement packagers could use systemd features without thinking about sysvinit. Playing around systemd should IMO not affect sysvinit and vice versa. For this particular case it would mean that using systemd should use /etc/tmpfiles.d/*.conf and sysvinit uses /etc/sysconfig/cron only. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ruediger Meier <sweet_f_a@gmx.de> writes: Thanks for feedback.
Yes, but this would not save us from re-writing the docs on the variables in /etc/sysconfig/cron. The statements there are just too broad. At least, we must add warnings that sysconfig settings are not valid for systemd. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 06 December 2011, Karl Eichwalder wrote:
Ruediger Meier <sweet_f_a@gmx.de> writes:
My idea is to have really distinct systemd and sysvinit installations. If you have systemd installed then there would be only /etc/tmpfiles.d/* and no more /etc/sysconfig/cron and vice versa. If a user wants to change from systemd to sysvinit then there could be a script which converts different config files (Or just a warning that you will get a totally different behaving system using a lot different config files). This implies that you can't switch between systemd and sysvinit at boot time. IMO mixing systemd and sysvinit like done in 12.1 is very bad thing. The reason why this was done is probably to have a working fallback from systemd. But sysvinit can't be a working fallback if it depends on systemd. Moreover leaving both systemd and sysvinit users with many invalid documentation and unused/redundant config files and incomplete ReleaseNotes about major changes was even worse. BTW on this list I've read dozens of times something like "you should learn to do systemd stuff natively". I think this applies also when you end up with non-booting system(d)s: "you should learn to repair systemd rather than expecting a sysvinit fallback". cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 6, 2011, at 03:43 PM, Ruediger Meier wrote:
Hold on, cron isn't dead yet :) /etc/sysconfig/cron controls other aspects of cron's functionality too. It may be one day that systemd expands to encompass all of cron's functionalities but until then I think the better solution is to properly mark the settings in /etc/sysconfig/cron which are deprecated by systemd, and point the user to the correct file(s) where the equivalent systemd settings are (or proper documentation describing how to do it). Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/11 12:24, Tim Edwards wrote:
Yes, https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/Systemd.timer specifically. however this is not yet meant as a replacement for cron. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/11 11:43, Ruediger Meier wrote:
Well, yeah, it is in transition mode, maintaining 2 separate init systems is a royal pain in the ass, something that no-ones wants to do, at some point sysvinit will go away,hopefully in 1 or 2 release cycles. Work is being done now to migrate the remaining legacy init scripts to reach a point when we cleanly switch. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 06 décembre 2011 à 12:28 -0300, Cristian Rodríguez a écrit :
Sidenote : we don't need to migrate sysv services to systemd unit files to "drop" sysvinit as an init system, since systemd handles sysv services correctly.. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 06 December 2011, Cristian Rodríguez wrote:
Yup but maintaining both _plus_ keeping both behavior in sync is even more pain and not even possible as you see in 12.1.
at some point sysvinit will go away,hopefully in 1 or 2 release cycles.
Decoupling sysvinit and systemd would make it possible to let users and packagers decide what they want to maintain/use. Improving systemd support should not affect current sysvinit support. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 06 of December 2011 12:28EN, Cristian Rodríguez wrote:
at some point sysvinit will go away,hopefully in 1 or 2 release cycles.
When was this decision made and who decided it? I hope it's still not too late to reconsider it. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/11 14:05, Michal Kubeček wrote:
It has not been decided, but Im pretty sure we cannot maintain 2 init systems for a long time.. IMHO it could remain in the repos, as unsupported "at your own risk" and not installed by default for some time. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 06, 2011 at 06:05:17PM +0100, Michal Kubeček wrote:
This will get decided by those doing the work. Unfortunately pieces of the SUSE syslog package are not used by any other vendors. This is causing trouble and more trouble means more work. And this work has to be done by someone. What's the current issue? It's caused by a piece named blogd. A very, very nice piece of software which ensured over many years to create a boot log file (/var/log/boot.msg) including all messages from the beginning till the end. Unfortunately blogd doesn't work at the moment with a 3.x Linux kernel in the shutdown case well. See https://bugzilla.novell.com/show_bug.cgi?id=730193 (bnc#730193). Ok, we drop the Linux kernel. ;) systemd recently got a feature named 'Journal'. See https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUE... I hope this will address the missing feature. Cheers Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Tuesday 06 December 2011 20:00:34 Cristian Rodríguez wrote:
Yea let them well here's one thermic lance up the rear lets have things that dont need yet more tools to read them ALL logging should be plain text for ease of problem solving.. Next some pillock will be coming up with a dang registry file (no dount all binary ) dont like being able to configure things easily and wants it all in one file then you need a special tool to edit that and when it goes tits up whos sorts it out . plain text log files please .. Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 08:20 up 10 days 4:40, 5 users, load average: 0.00, 0.00, 0.00 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 07.12.2011 09:24, schrieb Peter Nikolic:
plain text log files please ..
So that attackers can easily mangle them. Yeah, good idea! ;-) -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 07 December 2011 09:48:42 Stefan Seyfried wrote:
Well should not be so wide open to them then simple pete -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 16:12 up 10 days 12:33, 5 users, load average: 0.21, 0.21, 0.10 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/12/11 13:13, Peter Nikolic wrote:
Well should not be so wide open to them then simple
That's not possible... any process can claim to be $yourfavoritesoftware. there is no authentication nor access control, by design. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 07 December 2011, Cristian Rodríguez wrote:
? They were talking about reading log files. BTW there is no security difference regardless whether logfiles are text or binary. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/12/11 14:08, Ruediger Meier wrote:
No, stefan replied saying that logs files can be manipulated by attackers, particulary writting fake syslog messages. If you have an idea on how to make the messages authenticated, have access control, metadata, a single structure, all of that suitable for servers that log lots of stuff per second in a plain text file, without breaking already existent syslog implementations and tools ..bring it on. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07.12.2011 19:21, Cristian Rodríguez wrote:
I remember having played with setting some log files "append only" to protect them. long ago. That way they can not be modified, just writing to the end of file is permitted. I also then remember using lcap to remove the ability to change the append-only flag, CAP_LINUX_IMMUTABLE and ability to do raw I/O. I faintly remember having some problems that made me stop the experiment. I thing at least logrotate didn't work and there may have been some other stuff. Anyways, the intention was to make it impossible for the intruder to change logs. I'm sure it can be done... Vahis -- http://waxborg.servepics.com openSUSE 11.4 (x86_64) 2.6.37.6-0.9-default main host openSUSE 12.1 (x86_64) 3.1.1-48-desktop Tumbleweed in VirtualBox openSUSE 12.1 (i586) 3.1.0-1.2-desktop in EeePC 900 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Cristian Rodríguez <crrodriguez@opensuse.org> [2011-12-07 17:52]:
Both statements are plain wrong, the rsyslogd version shipped with 12.1 can be configured to obtain the pid from the log socket so that not any process can claim to be another. The current development version expands this functionality considerably: http://rsyslog.com/what-are-trusted-properties/ -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 07 December 2011, Peter Nikolic wrote:
The good thing about journald is that it works for systemd only. So no need to flame against this particular piece of crap but concentrate on systemd :) Moreover it wouldn't be Poettering style if systemd would not even depend on journald soon. In this case journald will just be another good argument against systemd and for still keeping sysvinit maintained. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/12/11 05:24, Peter Nikolic wrote:
plain text log files please ..
Plain old syslog is not going anywhere, can still be used for traditional logging, you have rsyslog, syslog-ng, etc to choose from. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday, December 07, 2011 08:24:06 AM Peter Nikolic wrote:
plain text log files please ..
I liked that argument and repeated it a lot, but what means plain text. Log is not paper copy, which requires only eyes to read it. It is long string of characters written as one or more strings on a hard disk using file system. There is nothing to see if you don't have running a pile of software starting with kernel and ending with text editor. Even with all that you have to know meaning of fields to be able to understand each line. Then when you understand each line you need other software that will collect data from multiple lines spread accross log file, to actually understand what is going on. Having specialized editor for log files can only improve our ability to make use of logs, and then "text only" makes no more sense, as it is just inefficient way to store and later parse event data. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 25 December 2011 04:46:49 Rajko M. wrote:
Ok lets try another way round that then shall we hows about Human Readable not containing any of the upper 128 Chars of the Character set .
Nope just plain old boring no special tools text please the only way lets get away from this darn windowsisation of Linux and head back to a more friendly way of life Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 08:24 up 23:39, 4 users, load average: 1.02, 1.05, 1.07 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday, December 25, 2011 08:31:18 AM Peter Nikolic wrote:
No it is not. Human readbale is what you can see with your eyes, not with a help of the computer programs; just as stated in previous email:
Log is not paper copy, which requires only eyes to read it.
If you need text editor, bash and kernel to read something, then what is the difference to use specialized, a little bit more complicated editor that will output text that you can read, but that text will be stored in way that is convenient for computer to handle it, and it take lesser space on a disk. What you loose? 1) Ability to use primitive interface between you and logs that have to be huge just to satisfy that primitive interface. 2) Need to learn log file format. 3) Need to compress log every now and then with logrotate. 4) Need to expand logs when you want to read archived copies created with logrotate. What you gain? 1) Ability to store more information in the same space. 2) Ability to write and read logs faster then before. 3) Ability to scan for events faster then before. ...
"Darn windowization" :) Ideologists are in general detached from reality. There are good and bad ways get work done with huge gray zone between them. Is it forbidden to go forward, use better way to do a job, just because it resembles on some other (proprietary) solutions?
I feel I'm missing part of the thread. But anyway, I can recognize this as a discussion about the binary log, so let's hack at it: On Mon, Dec 26, 2011 at 3:00 AM, Rajko M. <rmatov101@charter.net> wrote:
2) Need to learn log file format. That's not an issue with syslog, which has/can use standardized formats. [0]
3) Need to compress log every now and then with logrotate. Don't kid yourself: binary logs will need compression just as well.
And you don't loose the need, with binary logs, you'll need to expand them just as well (ie: use a tool to parse the binary data and present it in human readable terms) [1]
Granted, standardization (either in binary or text form) helps a lot here. [0] what people is actually after is standardization. I theorize that the whole point about this binary logging fuzz is forcing standardization. Binary logs leave no option than to standardize. But they also bring tons of inconveniences. A more directed effort would focus on standardized and complete logging formats (ie: standard across distributions and apps, while containing all the information that might be required, and perhaps the possibility to add extra information fields if needed) [1] human readable is not about character set, it's about words. Human readable means an alphanumeric representation that can be easily understood by a human without software aids (other than display). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 December 2011 06:41:01 Claudio Freire wrote:
Thanks Claudio very well put Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 09:35 up 9:18, 4 users, load average: 0.94, 0.98, 0.76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.12.2011 07:41, schrieb Claudio Freire:
If you've really ever done real forensics, you'd probably value signed tamper-proof log entries.
I really want to see someone read /var/log/messages without software aid. I cannot. And there is no reason why "less" will not gain the ability to read journal entries, just like it is able to read messages.gz. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le 26/12/2011 16:00, Stefan Seyfried a écrit :
human readable mean with as little machine help as possible, and on evry system. Full ASCII is readable everywhere, even on a smartphone, windows or any system recovery. It's printable as raw data on most printer. that's why plain text config is so good. xml is the worst case I can still accept, because it needs only rtfm or some judgement to understand and logs may have to be read from as harsh tool as dd and hex editor is a HDD fails by the way this may be a lost battle, applications needs more and more complex data, so more and more complex logs. Where is the human being there :-( :-)) jdd -- http://www.dodin.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Seyfried <stefan.seyfried@googlemail.com> writes:
That just proves that you've never done forensics. Relying on tamper-proofness is a bad idea. The whole feature is a typical thing some people seem to assume that everyone needs. I imagine the reader software will be designed to detect such `tampering' and invalidate it one way or the other. Just imagine a dying disk flipping bits at random with a probability of X. At some point either the signature will be invalid, or the data. Having discarded valuable redundancy by using a binary format, how do you detect the validity and how do you cope with situations like these?
I don't want to depend on that particular less feature, at least not in real-life stress situations. It pains me to see that some people seem to scale their experience with 2 or 3 computers to a farm of 10000+ computers. It's a LOT different. Let's not forget this is new territory for anyone that hasn't done a similar migration (for the better or worse) in the past, promises mean nothing, *experience* is what counts. I could bore you all with stories about a similar movements in the financial industry (it was more about latency and parsing speed rather than tamper safety, etc.). But the fact is that the plain text standard FIX is still by far the most wide-spread despite several attempts to binarify it. I can't help but see similarities between the discussions back then and now. Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.12.2011 17:03, schrieb Sebastian Freundt:
No, if not implemented totally braindead, then it will just flag the entry as "has a problem".
If you're doing forensics on a dying disc, then that problem flag is a sign of "oh, a flipped bit!". But if you are doing forensics after a security breach, then it is a sign of "someone tried to do something bad".
I don't want to depend on that particular less feature, at least not in real-life stress situations.
You also depend on your dynamic linker still working. I have seen too many machines where it was not, so I finally had to get out that rescue system. So what.
It pains me to see that some people seem to scale their experience with 2
or 3 computers to a farm of 10000+ computers. It's a LOT different.
Thanks for assuming I'm not farming 10000+ computers. You're wrong.
So you surely have filed lots of bugzilla entries about all that bad experience? It is pretty rude assuming that the guys who are actually volunteering to do parts the work (Cristian is) will certainly screw up. If I'm looking at Cristians track record regarding openSUSE, I am willing to give him some credit and I assume that he will not screw this up. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Seyfried <stefan.seyfried@googlemail.com> writes: [snip]
Yes I have reported the bugs that most concern me. And none of them got fixed. Great track record. I'm not whole-heartedly discussing this anymore because I decided against opensuse and SLES. Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/12/11 13:15, Stefan Seyfried wrote:
It is pretty rude assuming that the guys who are actually volunteering to do parts the work (Cristian is) will certainly screw up.
Well, mounting an argumentum ad hominem is the favorite tool of those who lack of ideas ;)
If I'm looking at Cristians track record regarding openSUSE, I am willing to give him some credit and I assume that he will not screw this up.
Now to clarify some things, I am looking into this, making parts of the integration work, particulary the migration path to systemd and taking the time to understand how it works. In no way Im going to do it all that goes without saying I guess :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Dec 26, 2011 at 12:00 PM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Yes, I do. But that can be done with text too. Ever heared of GPG ASCII armor? (I do cryptography and security too, before anyone questions my competence on the field)
Never did myself. I always grep for quick insight. Can you grep binary logs? [0]
And there is no reason why "less" will not gain the ability to read journal entries, just like it is able to read messages.gz.
Will sed too? Will tail? Will all the other text tools? [0] There's no denying that text processing tools far outnumber journal processing tools. Remember, it all started when some guy wrote a set of text processing tools for IBM. And that it would be dreaming in colors to expect all those tools to be "upgraded" to work with journal files. Mostly because it's indeed outside the scope of those tools. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.12.2011 17:16, schrieb Claudio Freire:
But all you need is some kind of "jcat" or whatever it will be called to dump the human-readable version out of the database to stdout. Then all your text tools will do exactly as good as with your plain text logfile. No difference to messages.gz. There you also need zcat before you can process it with sed or whatever. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Dec 26, 2011 at 1:19 PM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Yes, that solves interoperability with text tools. But then you have the other case that has been pointed already: what if the binary log gets corrupted and jcat can't read it? Text logs allow the human behind the keyboard some recourse left: guess what's wrong with the log, try to make something of it regardless of corruption. Binary logs don't, unless you code very sophisticated tools. In essence, I believe the binary part is totally unnecessary and risk-prone. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/12/11 13:19, Stefan Seyfried wrote:
A quick look the yet to be released source will tell us that it "jounrnalctl" supports dumping logs in json and text formats. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Dec 26, 2011 at 10:00 AM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
I have done the work and definitely would love signed tamper-proof logs. I have reviewed FTP, Webserver, and SMTP logs for legal reasons. It complicates life not knowing if those logs can be truly trusted as really having been originated by the daemon in question. Note that it is too late by the time the investigation starts. The underlying logging needs to be tamper resistant from prior to the incident under investigation. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Dec 26, 2011 at 5:22 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
That will never happen. In order to sign entries, the logging daemon needs to have the keys. The task can be made very difficult, but the jist is, if the daemon can have access to the signing keys, so does an attacker that compromises the daemon. So, it cannot be made provably secure for legal purposes. But it *can* be made difficult for most attackers, a good yet not infalible protection for practical purposes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/26/2011 4:45 PM, Claudio Freire wrote:
Or, it may just be a great way to allow people in power to delude themselves longer. Things stay hacked longer because idiots believe the logs "prove" they have not been hacked. People go to jail because the logs "prove" they did something. People don't go to jail because the logs "prove" they didn't do something. Idiots in positions of authority routinely mis-use the tools to everyone's harm, and new admins routinely over-trust claims of quality/effectiveness. Remember http://news.ycombinator.com/item?id=3088687 ? They were convinced everything the they saw from their end must be true. At least no one can expect that a plain file can really prove anything by itself. I am intrigued by the idea of utterly trustworthy logs but I don't think they can really exist as easily as that. So again it's just a bad trade. You lose compatibility and flexibility, and gain essentially nothing. This is an example of "progress often isn't". Someone get's an idea, and since they're new they think it's a fine idea, and since all the rest of their generation are just as new they also all think it's a fine idea. Doesn't make it a fine idea. 10 or 15 years after AOL and Microsoft put the internet and email into the hands of the unwashed masses, a research paper came out that "discovered" what the cranky old timers who suddenly comprised only .001% of the internet had been saying since day one to the other 99.99% about the wasted time and effort and increased miscommunications from top-posting. It was very funny reading them "discover" this. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/12/11 18:45, Claudio Freire wrote:
In order to sign entries, the logging daemon needs to have the keys.
There are no keys...looks like nobody has bothered to read anything at all. :-| -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Dec 26, 2011 at 9:27 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
It uses chained hashes. Keyed or not, don't remember. If they're not keyed, anyone can falsify records, they only have to rewrite all hashes. So I assume they're keyed. If they are, my earlier point holds. Hence, no security in any case. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/12/11 23:32, Claudio Freire wrote:
"in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-once location, the full chain is authenticated by it." So tampering any entry will cause a mismatch that can be easily detected, the attacker would have to rewrite the _whole_ content of the history of a particular user (journald stores 1 log for each system user) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 27, 2011 at 12:16 AM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
That's quite naive. Usually, you just want to fake or delete the last few records. Deleting is quite simple. Altering the latest records too, since they haven't yet been backed up. In fact, even without hashes, if you back up your logs, you can authenticate against the backups. So, the hashes are useless complexity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27/12/11 00:35, Claudio Freire wrote:
Usually, you just want to fake or delete the last few records. Deleting is quite simple.
Sure, nothing blocks an attacker that has gained root access to simple rm -rf /var/log/journal/foo.journal
Altering the latest records too, since they haven't yet been backed up.
how ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 27, 2011 at 1:07 AM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
Altering the latest records too, since they haven't yet been backed up.
how ?
Inject and run a program that does the alteration. Like a python script, python, which is installed in any linux host, has all the required cryptographic primitives. Or in any other way drop an egg shell that does that. Possibilities are quite varied. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27/12/11 01:51, Claudio Freire wrote:
Inject and run a program that does the alteration.
Without being noticed ? defeating tamper-evident Merkle trees ?
Or in any other way drop an egg shell that does that.
Possibilities are quite varied.
Yeah, I can also throw the box into a lake of fire.. :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 27, 2011 at 2:23 AM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
Inject and run a program that does the alteration.
Without being noticed ? defeating tamper-evident Merkle trees ?
Oh, sub-estimating the abilities, possibilities or motivation of your opponent is the first mistake any victim of a security breach commits. Yes, it is harder. Yes, I would like the feature. No, it's not as hard to beat as the author believes. It never is. It doesn't mean it's pointless to try and protect systems. It's, after all, a game of wits. You don't have to make it perfect, only better than your opponent. Remember, I said I would like such a feature, only you don't need binary formats for that. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.12.2011 06:40, schrieb Claudio Freire:
Remember, I said I would like such a feature, only you don't need binary formats for that.
Then show me your code that does it without :-) Talking is cheap. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.12.2011 03:32, schrieb Claudio Freire:
Exactly like they can easily insert a commit into a git repo and nobody will ever notice? -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Seyfried <stefan.seyfried@googlemail.com> writes:
Git lives and dies on being decentral and pushed regularly to independent locations. Surely if 99% of the git repos you find contain an injected commit, what makes *you* believe it isn't genuine? Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27/12/11 06:50, Sebastian Freundt wrote:
The journal will also support a network protocol that permits push and pull just like git. This has not been implemented yet, though. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 27, 2011 at 7:11 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
This may be my own limitation, but I cannot see how a log can be "distributed" (in the git sense). I mean, push, ok, like a streaming backup. Pull? I don't see that. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/12/11 03:41, Claudio Freire wrote:
3) Need to compress log every now and then with logrotate. Don't kid yourself: binary logs will need compression just as well.
the journal supports inline compression,in ONE format, LZMA, the sane, logical choice. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/26/2011 3:34 PM, Cristian Rodríguez wrote:
Oh my god you get funnier every post! "foo-of-the-day is the bestest foo evaarrrr the only sane foo to use evarrrrr!" -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/12/11 17:47, Brian K. White wrote:
sane foo to use evarrrrr!"
It is the best format currently available, technology may change in the future and proper adaptations may be done accordingly. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 December 2011 17:34:13 Cristian =?ISO-8859-1?Q?Rodr=EDguez?= wrote:
Isn't it true that with any compression format, any mistake anywhere will invalidate the decoding of all subsequent data, making it totally unreadable? The only way to avoid that is through redundancy, thus removing the benefits of compression in the first place. Besides which, the whole notion of tamper proof logs is silly from the start - there is just no such thing. If I achieve root on a system, I have access to every single key used to cryptographically sign anything (no, there can't be passwords for autonomous daemons, at best the password has to be typed in on boot, but after that the key will be available in RAM for root to read). And with the keys, I can generate any log you care to examine, and you won't be able to tell the difference. Sure, you can get around it, by limiting what root can do, or logging to another system, or to hardware unchangeable output such as a printer, but then you can do that with any logging system. Besides besides which, a new kind of logging system is hardly a valid argument in favour of ripping out the entire core infrastructure of the system. Most arguments in favour of systemd talk about moving forward, but I have yet to see anyone say why it is considered forward. I don't see that we get anything we didn't already have. Fedora lacked infrastructure that they get with systemd, but we already had all of that. And if someone thinks this logging system is neat, take it out and build a replacement for syslog I see systemd as a massive amount of work, that will net us exactly zero benefit in the end. It won't boot faster, it won't enable us to do anything new that we couldn't already do before, and we will have amassed a ton of bugs in the process. I still propose that we drop systemd completely Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.12.2011 22:15, schrieb Anders Johansson:
Isn't it true that with any compression format, any mistake anywhere will invalidate the decoding of all subsequent data, making it totally unreadable?
No, that isn't true. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 December 2011 22:42:17 Stefan Seyfried wrote:
Really? I'm not aware of any codecs that can handle data corruption, except for a few that have been developed for usenet that involve massive redundancy. Could you give an example? Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Dec 26, 2011 at 6:47 PM, Anders Johansson <ajh@nitio.de> wrote:
bzip2. You can loose blocks, but that only looses you a block, all blocks in bzip2 are independent. So you loose only a portion of compressed data. For lzma, I think (not as sure as with bzip2) blocks exist just as well, only in a different form. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 December 2011 18:50:56 Claudio Freire wrote:
Interesting, I didn't know that. I knew the algorithm broke on corruption, I didn't know they do a keyframe setup to get around it. I see the default block size is 900K, that's a huge chunk of log gone
For lzma, I think (not as sure as with bzip2) blocks exist just as well, only in a different form.
Good question. The bzip2 man page discusses it, but lzma/xz man pages don't. Still, it's not a feature of the algorithm itself. The algorithms fail completely on corrupt data. The important bit is how it's implemented in a tool. Maybe compress line by line? Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/12/11 19:29, Anders Johansson wrote: The important bit is how it's implemented in a
tool. Maybe compress line by line?
That's what it does, according to my understanding, note that we are talking about unrelased software :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/12/11 18:15, Anders Johansson wrote:
There is no PK in journald, the tamper resistant part is inspired in something very similar to git.
And what would be ripped exaclty ? you can still use syslog...
I still propose that we drop systemd completely
That's sums up all arguments I have heard agaisnt systemd "I do not like it", "it much work", etc..googling sadly reveals zero reasonable technical arguments against it, all you see falls into the following categories (and I googled a lot. before jumping into this ship) - Appeals to tradition --> we do things this way and works. - ad hominems --> Lennart is an ass, blabla.. - ad portability --> it is not portable therefore sucks, that the most utter bullshit frecuently heard from the BSD crowd. Portability in reality means "A whole bunch of code and ugly hacks to make it work in your obscure system" (just take a look at openssl in example) - People that claim cgroups are ugly/broken, wrong choir !! that's something to complain to kernel developers. - In general lack of understanding what systemd really does. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 27 December 2011 00:22:40 wrote:
Cristian , You need to go away and read and listen to yourself sometime seriously , So far up the butt end of this darn unwanted systend thing it is untrue ,, Me i dont really care as long as it WORKS and systend clearly is fatally flawed from the gorund up so it does not fit the bill of working and from what i can see NEVER WILL for the simple reason you would need to rewrite almost ever Linux program that uses the old solid working init system to fit with the NEW BROKEN systend Alpha quality stuff YMMV mine is not movable Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 07:43 up 1 day 7:26, 4 users, load average: 0.15, 0.10, 0.09 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez <crrodriguez@opensuse.org> writes: [snip]
Interesting that any discussion always revolves back to systemd. Might I add another category: - Hordes of unfixed bugs, many of them so major no production environment with a risk manager will dare even try this thing in its current state. Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Dienstag, 27. Dezember 2011, 09:56:34 schrieb Sebastian Freundt:
Cristian asked for bug numbers – not polemic and useless statements. Sven -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Sven Burmeister <sven.burmeister@gmx.net> writes:
Can't speak for other people, but here's the list of *my* reported/followed, still open bugs: On the novell bug tracker: 737547 automounter doesn't mount nfs shares 737553 rpc.idmapd not started automatically 737636 network is started then stopped right away 737690 systemd does not honour SIGPWR 738604 systemd corrupts disk and dumps core when ntp is started 737551 rpc_pipefs not mounted even though NFS_START_SERVICES="yes" and RPC_PIPEFS_DIR="/var/lib/nfs/rpc_pipefs" 737554 Boot output isn't directed to the console On the upstream tracker: 676856 In runlevel 1 (no network), it asks for NTP time, and hangs waiting for NTP service 698793 /home on NFS mounted partition 700825 Systemd automounts fail to handle connect/disconnect of network devices 713224 Hang during reboot - unable to umount partition 707731 Some partitions are mounted multiple times under certain conditions 719952 reboot or shutdown commands unresponsive during systemd-fsck 757463 NFS filesystems never unmounted, have to poweroff hard 758535 Restarting sshd kills current sessions 770471 systemd dumps core when ntp is started after fsck 759071 time is not correct after reboot If people were half as busy fixing those bugs as they are discussing the pros and cons, systemd might be a half-decent beta product already. Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27/12/11 09:57, Sebastian Freundt wrote:
what do you expect ? instant bug resolution ? the older bug of that list has been filled one week ago... I think you have to check out your expectations. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez <crrodriguez@opensuse.org> writes:
I didn't address you. It's the same endless discussions on the fedora list, and in particular I meant the redhat bug tracker, there are open bugs dating back to 2010. In particular the UsePAM ssh issue and the fsck issues are still unfixed, as I've showed with my 738604. This is more than disappointing seeing as the system overall isn't that complex and redhat has 6 guys man-power. To me this clearly indicates poor design. Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27/12/11 11:20, Sebastian Freundt wrote:
Cristian Rodríguez<crrodriguez@opensuse.org> writes:
To me it indicates that people have a lot of work and have to prioritize things that are really important or what their employer wants them to work in first. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 27, 2011 at 11:26 AM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
Whatever it means, however old the bug reports are, they're serious bugs you don't want in production servers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
I don't know what Sebastian expects -- I would have had expected an attitude that doesn't call for removal of sysvinit while there are such bugs, directly after a release that didn't even had a working postfix. I also wouldn't have had expected an attitude that uses the question "where are the bug numbers?" to squash discussion, and then complains when there are bug numbers cited. Especially when the complaints include wrong assertions. (That Sebastian opened one of those bugs last week doesn't imply that all of his bugs are from last week.) But obviously, these expectations have been wrong. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 28. Dezember 2011, 02:33:56 schrieb Joachim Schrod:
Are you sure there were never bugs in an openSUSE release that caused services not to start? According to your logic any of those would have indicated that systemv is utterly broken and must not be shipped as default. The RFC is for the next release. I do not see how starting it later would be any better regarding pointing out bugs and fixing them. In fact, if the testing of systemd would have got the attention from those complaining now at this stage and during the development cycle of the 12.1 release a lot more bugs would have been fixed already.
It does imply that if bugs are not reported they cannot get fixed. And it does imply that reporting bugs just before Christmas holidays will unlikely lead to them getting fixed within a week on the openSUSE part. Sounds reasonable to me.
But obviously, these expectations have been wrong.
Indeed, polemic emails lead to a more aggressive tone and thus nobody should have introduced any polemic statements or subjective comments but just bug numbers and issues in a neutral and objective and technical manner. An attitude that accuses somebody who is actually doing a lot of work on fixing bugs of having the wrong attitude seems questionable to me. Face it, systemv will be gone at some point and the only useful thing you can do to help is report and fix bugs. Endless discussions do not help improving anything. Sven -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Sven Burmeister <sven.burmeister@gmx.net> writes:
Well personally I was under the impression that 12.1 is fit for production use, only to find out it isn't, or to be less polemic, only to advise my risk managers that *I* think it isn't. I, as a user, certainly can't be asked to continuously assess everything that happens during the development cycle. I was instead assuming that the opensuse developers took a look at the upstream bug situation and tried some of those scenarios themselves, at least the not-too-specific ones.
So what's the official policy here? Do you want all the bugs from the upstream tracker that apply to opensuse in the novell tracker? Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 of December 2011 09:27EN, Sven Burmeister wrote:
Face it, systemv will be gone at some point and ...
Once again: is this already decided? If yes, who decided it and when? If not, please don't write things like this as if it was a decision already made. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2011/12/28 Michal Kubeček <mkubecek@suse.cz>:
I think the whole community decided. Tons of distros are moving away from sysvinit, and I can't blame them. It *is* really a chore to maintain it, and systemd *is* a lot simpler in the simple cases. I agree with the move. systemd goes forward in some areas. But, as any single-minded rewrite, it goes backwards in others. The whole systemd page seems to focus almost entirely on boot performance. Reliability, accountability... not a word. Well maybe one or two. So, I agree, sysvinit is going to be replaced by systemd. I just hope not right now. Because systemd (IMHO) is not up to par yet. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 of December 2011 11:24EN, Claudio Freire wrote:
Certainly not the _whole_ community.
Tons of distros are moving away from sysvinit, and I can't blame them.
I still take systemd in 12.1 as an experiment. An experiment that showed that if there ever will be time to replace normal init with systemd, it is definitely not now.
I agree with the move. systemd goes forward in some areas.
I don't. So far, I haven't seen any (useful) feature that systemd would provide that couldn't be with much less effort achived without it. On the other hand, it brings a lot of problems and complicates things that used to be simple and easy. Some features aren't provided at all and when people point it out, the answer is "you shouldn't want them because systemd doesn't provide them". Saving (possibly) few seconds of boot time is not worth the trouble. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2011/12/28 Michal Kubeček <mkubecek@suse.cz>:
Well, if you don't read the whole post, yes, I can see how you would answer like that. I think just the same. But some stuff *is* a lot easier to maintain with systemd. There's no denying. The problem is its shortsightedness and its refusal to, as you say, implement the features system administrators need. So maybe systemd is an experiment and maybe there will be a superd that supersedes it and fixes all of its mistakes while embracing all of what it did right. Or maybe systemd *can* be fixed. Point is, systemd *does* introduce some forward features, and the community *is* seeking for a sysvinit replacement. If it will be systemd or a successor I don't know. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 of December 2011 12:06EN, Claudio Freire wrote:
Well, if you don't read the whole post, yes, I can see how you would answer like that.
I read all of it. I just didn't quote (and comment) the parts I agree with. :-)
But some stuff *is* a lot easier to maintain with systemd. There's no denying.
I learned to dislike tools that make easy and usual tasks easier and any nontrivial or unusual task hard, tricky or even impossible. And unfortunately systemd is exactly this kind of a tool. What makes it even worse is the attitude "We created this scheme what a service should look like and the rest of the world is supposed to conform to this scheme." Simple and nice config files for basic set of "conforming" services are nice to have but not for the price we have to pay with systemd. Not if it means throwing away the flexibility and easy diagnostics of shell scripts.
I'm not sure. I don't like the motivation of this project. It tries to solve one problem that I don't consider that important (faster boot) and some problems that systemd developers even invented to be able to advocate for it (e.g. socket based dependencies). I'm not opposed to the idea (as such) of replacing System V style init. If there is a project that works at least as well as traditional init does and brings some significant advantages, then why not. This is the way netfilter replaced ipchains, NPTL replaced LinuxThreads or udev took over /dev. But current systemd is not such project and, moreover, it doesn't seem to want to be such project. They just claim that they do it in a different way so it simply must be better. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2011/12/28 Michal Kubeček <mkubecek@suse.cz>:
I agree completely with everything you said. Especially on socket stuff, weird feature indeed. I don't know who needed/asked for it. I'm hoping all those shortcomings you're pointing out in systemd, which are MAJOR, are going to be fixed (because they can be fixed). Because *then* I'd like to have systemd. Not now. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/12/11 12:41, Michal Kubeček wrote:
After been working for years in distro packaging, this is exactly what we need, conforming to one scheme. Systemd units can even be checked with rpmlint to verify if they really do what the say or what the packager wanted to do try to do that with shell scripts.
The shell is not a debugger is it ? I am missing something ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 28, 2011 at 2:54 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
I agree, but not to the point where you can't do things. Like ExecStatus, and the refusal to even consider it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 of December 2011 14:54EN, Cristian Rodríguez wrote:
After been working for years in distro packaging, this is exactly what we need, conforming to one scheme.
This might work if we developed all projects included in the distribution ourselves. But we don't. There are projects that are not written primarily for Linux and there are projects that are not developed with Linux in mind at all. These are not going to conform to "We decided daemons are bad, please rewrite your daemons not to be daemons."
I don't understand. If a systemd unit doesn't do what it says, it's a bug in systemd. The same for a shell script and bash. As for checking whether the unit file says what its author wanted it to say, I seriously doubt it is possible.
The shell is not a debugger is it ? I am missing something ?
If I want to know what is going on in an init script, I just add "-x" to the interpreter specification. I can add diagnostic commands (print a value, check whether a process is running or whether a file exists...) anywhere inside a script. I don't want to trade this convenience for few seconds of boot time. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29/12/11 04:24, Michal Kubeček wrote:
I don't understand.
Yeah, I see. If a systemd unit doesn't do what it says, it's a
bug in systemd.
This is not what Im talking about, what I mean is, as units cannot have arbitrary code they can be mass-checked at package build time, verifying they are written correctly, according to the already defined syntax and meaning of the different options. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Donnerstag, 29. Dezember 2011 schrieb Cristian Rodríguez:
Indeed, that's a big advantage. You can perfectly verify that the *.service file has ExecStart=/usr/bin/start-foo-wrapper and not ExecStars=/usr/bin/start-foo-wrapper *SCNR* (If you find any sarcasm in this mail, you may keep it ;-) Regards, Christian Boltz -- Ein Update ist meines Wissens die Erhöhung der Versionsnummer. Ob sich dabei die Qualität auch erhöht, ist manchmal fraglich. [Martin Ereth in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29/12/11 17:54, Christian Boltz wrote:
Yes, and verify if /usr/bin/start-foo-wrapper exists either on the package or in the installed system. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/29/2011 4:03 PM, Cristian Rodríguez wrote:
Just as rpmlint already checks that my init script defined in the spec file exists. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29/12/11 21:12, Brian K. White wrote:
Just as rpmlint already checks that my init script defined in the spec file exists.
No, it is not the same thing, -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 29 of December 2011 14:57EN, Cristian Rodríguez wrote:
Seriously?
...which is something completely different from "verify if they really do what they say" or even "what the packager wanted to do" (which you claimed). Next time, please, read your own mail first before you start to mock someone just because you don't agree with him. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello all, Is there any talk about adding a gui for systemd to Yast. Similar to the System Services. Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 03 January 2012 17:23:52 Roman Bysh wrote:
Hi Roman, I think it made sense to enhance the yast2-runlevel module if you want to add systemd specific stuff. You can find the source here: http://svn.opensuse.org/svn/yast/trunk/runlevel/ Patches are welcome! :-) Cheers, Thomas -- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/05/2012 11:29 AM, Thomas Goettlicher wrote:
There was an internal feature request for this, which is now open: https://features.opensuse.org/312568 Duncan
Le jeudi 05 janvier 2012 à 18:24 +0100, Duncan Mac-Vicar P. a écrit :
And some people started somehow (see https://bugzilla.novell.com/show_bug.cgi?id=664548 ) I strongly suggest to rely on dbus api to talk to systemd and detect which services are running (or not, etc..). This might require some enhancements to dbus support in yast. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2011-12-29 08:24, Michal Kubeček wrote:
With the old system, users can help and find/correct errors, tailor things for their particular needs. With systemd, few people can, we have to write bugzillas and wait instead. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8C85UACgkQja8UbcUWM1xUygD+Ld+IqZGvAt4MW0pgfWGcgSIW APpRX63B0OJHdIb50sAA/AtjwW2PFlnMvxdZp/rhseRwIvjQq8x8TRJy5osXOE+I =1J8Q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/01/12 09:24, Carlos E. R. wrote:
The lack of understanding of people is hardly a problem on systemd don't you think ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/6/2012 2:16 PM, Cristian Rodríguez wrote:
You continue to ignore problems that don't interest you, stating that they are invalid without demonstrating how or why. When people say "how do I do this with systemd" that is not an empty question, and requires an non-empty answer. As the person advocating a change, YOU are the one obligated to assume that whatever someone is doing right now via sysv init, it must be for a valid reason, and it is up to you to figure out and prove if it is not for a valid reason, and/or how to accomplish the same job via systemd. I can only assume the lack of understanding lies with you until you actually address these issues with something of more substance than merely claiming "that's not a problem" or "you're wrong for wanting to do that". Maybe they are, but they are not trying to inflict damage and disruption and expensive time and effort on anyone else. You are. I believe I have demonstrated enough understanding of my particular top problem by suggesting that at least one way to get a service (such as container-based vm's) that don't employ a constant daemon, but never the less do have a start action, a stop action, and a status action, is by adding a watchdog process that will serve as the always-running daemon process that systemd can then watch the way it expects to, and would perform those same actions that the init script currently does. But that's a shitty answer. That's a downgrade. I don't want or need another process running for this even if it would be a pretty light weight one. Ultimately, it's just adding a part to a system, thus increasing it's complexity and thus reducing it's robustness, by definition, inarguable, for no benefit AT ALL other than systemd pacification. None of the other almost-answers like static unit (vs service) or using the inotify or pidfile hooks can do the job that needs doing (yes I am quite familiar with inotify, I use it and incron for many things and I maintain up to date opensuse packages for many build targets in obs) but, all importantly, a fairly simple init script DOES, because it's a script, that performs actions and tests various conditions and calculates a correct and current answer based on that current info-gathering, and all of it is very application-specific and nothing that a generic service like systemd should ever have internal knowledge of. Now, if I'm wrong, and there IS a way to get all the proper functionality and behavior via systemd that I currently enjoy via sysv init, it is YOUR OBLIGATION, as the person who is trying to inflict such a disruptive change to such a long-standing core part of the system, to provide the drop-in systemd replacement. You will have to spend the time to understand what a container vm is, and how the current lxc tools work (and how the current libvirt lxc support does not), including the concept of application/service containers vs full system containers. You will have to forgive everyone whose life you are impacting for not being sympathetic that this would be a lot of work and consume a lot of your time. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/01/12 17:45, Brian K. White wrote:
You continue to ignore problems that don't interest you.
Well, yeah, problems that do not interest me will likely be addressed by someone else.
stating that they are invalid without demonstrating how or why.
It is not up to me to demostrate that.
When people say "how do I do this with systemd" that is not an empty question, and requires an non-empty answer.
The documentation answers most if not all of the questions.
You are fooling yourself, you are entitled to believe that sysv scripts do what you want, but that does not make it true why ? in sysvinit processes escape the init system, and control cannot be regained. It may tell you that it is working or running, when it is not or is running under a different PID, there is no way to "contain" them, hence no way to determine in a reliable way if what "status" says is true.
NO, I dont have any obligation, I am a volunteer, I do what I can or what I care about.
I am not trying to inflict anything ... people always can choose something else or keep maintaining other init systems if they have interest or skills, anyone can step up to the task of taking care of this legacy systems, lots of luck with that. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jan 6, 2012 at 4:16 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
Christian, you may not be trying to inflict anything. But you RFC if implemented clearly would. The reason this thread got so emotional is your RFC called for updating OBS to force packagers to drop support of sysvinit. So while you personally may have no obligation, I agree that the proponents (as a whole) of the proposal to have OBS force packagers to drop sysvinit support have an obligation to show systemd is fully able to take over the job. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2012-01-06 at 17:04 -0500, Greg Freemyer wrote:
Absolutely! - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk8IPkIACgkQtTMYHG2NR9XtBQCbBjBJuMc4JXMQKM6dlEj2pDHM /E8AniTMkRNv+VW3YEu+1myj2gw2PdTj =1b31 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2012-01-06 at 16:16 -0300, Cristian Rodríguez wrote:
I think it is. We can not help. You are on your own. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk8IPcEACgkQtTMYHG2NR9WlVgCeNjHjAlVczpVuIkfAkAoAhrp9 PLgAnA3PUIq7xLx02uHVC/06hRsnv51H =mPIj -----END PGP SIGNATURE-----
Michal Kubeček wrote:
+1. -- Per Jessen, Zürich (3.3°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2011-12-28 17:21, Per Jessen wrote:
+1 - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8C8q8ACgkQja8UbcUWM1zQeAD/T5kn2Odfe+JVcMXXFLv/P7/X jy0/XW2SJUTccMIbEagA/jMytzKvJf6+DiGi2sk8n8BCLmVPq9+sRN8kvQ9oMB6z =V2Xc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/12/11 11:49, Michal Kubeček wrote:
Yeah, simple and easy... did you mean obscure, undocumented, racy and impossible to verify in large scale ? Some features aren't provided at all and
when people point it out, the answer is "you shouldn't want them because systemd doesn't provide them"
Well, people is asking for fairly ridiculous things. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 December 2011 18:04:36 Cristian Rodríguez wrote:
If people want certain things and systemd is unable to provide them then systemd has no place to be there simple as . Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 18:54 up 2 days 18:37, 5 users, load average: 1.23, 1.21, 1.18 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/12/11 15:55, Peter Nikolic wrote:
If people want certain things and systemd is unable to provide them then systemd has no place to be there simple as .
People wantings things does not mean what they want is correct. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 28, 2011 at 4:30 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
Ok, now this actually has a lot to do with the RFC. I read on systemd's page:
I seem to recall system rescue and live dvds using that interactivity to query the user at boot time what to do or to provide an emergency shell. How is that handled with systemd? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 décembre 2011 à 17:10 -0300, Claudio Freire a écrit :
It is handled the same way systemd handle runlevel 3 ie, it works perfectly.. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jan 3, 2012 at 9:31 AM, Frederic Crozat <fcrozat@suse.com> wrote:
You mean to say an "ask-the-user-something" target that starts a tty with the interface, and after getting an answer it invokes the "do-the-rest" target? Seems to be significantly different from the current method. I like it better than the current method, though. But it does mean that the roadmap has to take into account the migration of those features. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 03 janvier 2012 à 13:39 -0300, Claudio Freire a écrit :
I mean it starts an emergency shell and once this shell is exited, it will start the standard boot. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 of December 2011 16:30EN, Cristian Rodríguez wrote:
This is exactly what I dislike most about systemd and its lobby. They defined their narrow view of the world and everything that doesn't fit into this view is dismissed as "wrong". Some time ago, someone used an analogy of horses and cars (to represent traditional init and systemd). And this demonstrates why this analogy is completely wrong: when cars were invented, nobody took horses away from people. Nobody said: "Horses are bad, from now on, you have to use cars even if they cannot replace horses for your purposes; if this is the case, your usage pattern is wrong." The cars had to win in a fair contest. Why don't you want to let systemd to (try to) win in a fair contest as well? Do you think system admins are stupid so that you have to take the decision from them for their own good? Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 29. Dezember 2011, 08:40:23 schrieb Michal =?utf-8?B?S3ViZcSNZWs=?=:
Nobody forces anybody to use anything. You have a choice of distro and OS. According to your analogy all that happens is that your local horse salesman decided to sell only cars an no horses anymore. Nobody forces you to give-up the horses you are riding, nobody forces you to stay with your salesman – and if that salesman took the wrong decision he will go bankrupt. Place your bets! :-) Sven -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/29/2011 4:20 AM, Sven Burmeister wrote:
Popularity does not define goodness. Billions of people drink Coca-Cola and eat McDonalds. The ability to get the majority of people to do something implies nothing about it's virtue. Horses couldn't haul 40,000 lbs at 75 mph for 3 days straight across the country, or be ignored in a garage for storage with 0 maintenance indefinitely. But you did actually give up a lot. I would love a car that ate fuel that grows (renewable) everywhere, drives itself, and even reproduces itself. Which was one reason that switch was rather gradual. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29/12/11 20:55, Brian K. White wrote:
Popularity does not define goodness. Billions of people drink Coca-Cola and eat McDonalds.
Well, yeah, however you might want to consider the following: sysvinit developers: 1 (Werner, brave human being that tackles this increasingly aging beast, kudos) systemd devs: distributed, 55 comitters. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 28.12.2011 19:55, schrieb Peter Nikolic:
If people want certain things and systemd is unable to provide them then systemd has no place to be there simple as .
If people want certain things and SysV init is unable to provide them then SysV init has no place to be there simple as . -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 28. Dezember 2011, 22:28:24 schrieb Stefan Seyfried:
He does not even stick to his own logic. Trying to show him how useless his polemic statements are won't work, because of that and because they are based on ideology and not facts. Sven -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 December 2011 22:15:46 Sven Burmeister wrote:
Think it is time for a complete shake up at openSuse cus it is going to go the way of the EU down the tubes -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 23:58 up 2 days 23:40, 4 users, load average: 0.00, 0.16, 0.85 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 28. Dezember 2011, 23:59:58 schrieb Peter Nikolic:
It's sad that you do not notice anymore how frustration-driven your attitude and hence most probably life is. You hardly ever present any arguments but just polemic statements, allegations, threats, generalisations, over- simplifications, rants etc. You cannot bite anything or anyone, simply because you lack sovereignty. So please present arguments if you are interested in contributing to the technical part of this discussion and not just boulevard newspaper style content. Sven -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Sven Burmeister <sven.burmeister@gmx.net> [12-29-11 05:16]:
excellent :^) -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
Hasn't been much of a problem so far. Or do you have a list of applicable bug reports?
Oh yeah. Like output from init scripts. Yup. -- Per Jessen, Zürich (2.1°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/12/11 16:01, Per Jessen wrote:
Try the following, create a program that is able to figure out what exactly init scripts do, if it really is what the packager intended. Also try auditing all uses of /tmp , sed , awk, etc ensuring people are using them correctly.
Im not talking about incompatibilities or bugs, I am talking about requests that ask for systemd to manage services that do not provide proper exit status codes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez <crrodriguez@opensuse.org> writes:
I think that's where your misconception comes from: Not you, the packager, have to decide what I, the user, want to do. I want automounted NFS shares, they worked before. The shell script just mounted rpc_pipefs and started the idmapd, I can do that manually if need be. Systemd fails doing either, and on top of that it also shuts down the network for some obscure reasons. Did *you* intend that? If so why? If not, why is it so hard to fix if everything is clear, documented, non-racy and possible? Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/12/11 17:02, Sebastian Freundt wrote:
I think that's where your misconception comes from: Not you, the packager, have to decide what I, the user, want to do.
Neither you the user has to determine in what I, the packager, invest my time on nor what i should spend years supporting.
I want automounted NFS shares, they worked before.
As you probably saw in in bugzilla, I am taking a look at your bug report, and indeed have made changes to solve the problem that now I need to test. The shell script just mounted rpc_pipefs and
started the idmapd, I can do that manually if need be.
Your bug report was filled 2011-12-18, do you really expect people to left behind their vacations, holidays, whatever to attend a problem ?
Systemd fails doing either.
As I said above I'm working on it, so far it does not include changing anything of systemd , because it is not at fault.
I'm getting slighty tired of repeating this, THOSE ARE BUGS THAT EXISTS ELSEWHERE !!! :-@ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
One would sincerely hope that you, the volunteer packager, invest your time such that the user will appreciate and enjoy what you spend your time doing. That is certainly how I do voluntary work. -- Per Jessen, Zürich (0.8°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 28.12.2011 21:53, schrieb Per Jessen:
Cristian Rodríguez wrote:
I am a user and I appreciate and enjoy what Cristian is doing. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2011-12-28 21:53, Per Jessen wrote:
+1 - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8C+90ACgkQja8UbcUWM1wvAwD+IoqFNH1k1nrgMn9WRDz/lcnK fma9nsFgZbNhh5jQqYoA/3ltu64wG8hHW61zdNT0ruKnh72mmtX/hotDmxowDRvk =E5Qc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
Like I said, none of this has been much of an issue so far - I agree it could be desirable to verify some of this, but that is a pretty poor argument in this context.
It is the other way around - systemd wants/needs to manage those services, but somehow systemd does not accommodate them. (and they were there first). -- Per Jessen, Zürich (0.7°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Mittwoch, 28. Dezember 2011 schrieb Cristian Rodríguez:
On 28/12/11 16:01, Per Jessen wrote:
Cristian Rodríguez wrote:
Try the following, create a program that is able to figure out what exactly init scripts do,
It already exists and is called /bin/bash -x (I know that this probably isn't the answer you wanted to hear ;-)
if it really is what the packager intended.
Now it becomes really interesting. You have a device to read /dev/brain? Please tell me where I can buy it! ;-) OK, enough fun for one mail ;-) I agree with you that service files are much easier to parse than initscripts. Nonetheless that's only useful if the ExecStart points to the daemon directly - the argument becomes pointless if ExecStarts runs a wrapper script.
Also try auditing all uses of /tmp , sed , awk, etc ensuring people are using them correctly.
Auditing (temp)file usage is easy. That's something aa-genprof (and in general, AppArmor in learning mode) can do easily.
That method works for starting daemons, and I agree that they should provide proper exit status codes. OTOH, I already explained some days ago that in some cases (like AppArmor) ExecStatus would really make sense because there is no daemon/process you can check. To make things more practical: I'm currently rewriting PostfixAdmin from linear PHP files to using classes, and there are lots of similarities with the initscript vs. systemd discussion. Just to name an example: the new code can generate HTML forms based on an array, so basically adding a new module to PostfixAdmin means to create a new class that defines an array containing the database fields relevant for that module, and you get all the handling (read from database, store in database, input validation etc. automatically). Sounds easy? In theory it is - just validate the form input and store it in the database. Unfortunately, there are lots of exceptions. For example - when creating a mailbox, an alias for it needs to be added, and a mail needs to be sent to create the mailbox on disk - the "password" and "repeat password" fields have to match - checking password strength is good, but users will kill me if I do the same with their remote passwords when setting up fetchmail jobs - in the web form, creating aliases and mailboxes is easier with a split localpart text input and domain dropdown, but the class and the database expect the complete mail address - data read from the database may need post-processing (for example to find out if a mailbox alias is forward-only or store-and-forward) - and much more (and please keep in mind that PostfixAdmin "just" fills some database tables that are then used by postfix) Needless to say that I had to add *lots of hooks* to support all those exceptions - otherwise I would need to rewrite/overwrite the whole "store" function from the parent class just to send out a mail and create an alias when creating a mailbox. Instead, I can write a small "storemore" function where I can do the additional tasks, and let the parent class' store function do the main job. To come back to systemd and AppArmor: Yes, I can of course start a watchdog daemon in ExecStart that (after loading the profiles) runs aa-status every 10 seconds and errors out if something goes wrong. And I really would check every 10 seconds so that everybody running "systemctl status" gets an (at least nearly) up-to- date result. Or I could use the ExecStatus "hook" in the service file, which could then run aa-status when someone runs "systemctl status". Now please tell me which way is smarter ;-) Regards, Christian Boltz -- if this crashes as well, make sure to create a bnc entry, add a backtrace, a copy of your sysconfig/proxy file and some cheese (Want to make a fondue). [Dominique Leuenberger in opensuse-factory] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/12/11 20:54, Christian Boltz wrote:
Of course Im not talking about that.
Auditing (temp)file usage is easy. That's something aa-genprof (and in general, AppArmor in learning mode) can do easily.
Will it catch all sorts of bugs ? like writting directly to /tmp without using mktemp or using sed with output to /tmp/namedfile ?
I still don't get it, what do you want to do, that cannot be done already with ExecStart ? did you read the documentation ?
Let me get this straight. - Apparmor is security software, which people depends to secure their systems, but does not provide any meaningful way to know it is loaded ? I expect something like this, especially if we are talking about security !! - Apparmor parses its rules, if there is a ERROR according to their own concept of error, it aborts loading and returns failure exit code. - If there is an error, that happens after parsing (loading), again according to its own rules, the transaction is rolled back, in an all or nothing fashion and returns failure exit code, no half loading, no inconsistent status. Whatever else is a recipe for disaster... what I am missing here ? it is just my idea or apparmor concept of starting is totally brain dead ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Mittwoch, 28. Dezember 2011 schrieb Cristian Rodríguez:
(nice to see that you skip the more interesting questions. I would really like to hear something about your /dev/brain interface...)
It will give you a list of files, and what was done with them (read, write, exec etc.). If you re-run the initscript and get the same set of tempfile names, then something smells very fishy ;-) I know systemd supports "private /tmp" (IIRC as in "a private subdir of /tmp that looks like /tmp itsself to the process"), and yes, that's a good feature and adds some security. But unfortunately there are some things that _need_ the shared /tmp for some reason (for sockets etc.) And there could also be attackers who inject files in a "private" /tmp/*/ directory after it has been created. In other words, even with private /tmp/*/ directories, you _still need to write secure programs_. Obviously there is no automatism that can catch _all_ sort of bugs - otherwise the security team would have been fired years ago (and we all know they still have enough work) ;-)
See below.
did you read the documentation ?
Yes, I did.
It does provide a way to check the status - but not in the way systemd likes;-) There is nothing like a process or a pid file (both wouldn't make any sense). Instead, the "aa-status" script will give you all you need - including nice $? values. But: *** You have to run it! *** systemd could also read from /proc itsself (basically that's what aa- status does) - but that would mean to have AppArmor-specific code (instead of a generic ExecStatus "hook") in systemd. I don't need to explain you which way is better, right? (And I hope Ludwig enjoys his popcorn (or leftover christmas cookies) while I fight for a feature he'll also need for SuSEfirewall ;-)
Yes, of course.
You are still talking about "startup", and yes, at startup phase there is error handling and proper exit codes.
Whatever else is a recipe for disaster... what I am missing here ?
You are talking about startup ("rcapparmor start"). I am talking about checking the status _later_, _after startup_ ("rcapparmor status").
it is just my idea or apparmor concept of starting is totally brain dead ?
Someone could manually unload all AppArmor profiles (by manually running apparmor_parser -R) and systemd would still tell you "apparmor: running" because it was started by systemd. If something is brain dead, then it must be systemd's assumption "I loaded it, so it must still be there". The correct check is to run "aa-status", and this is why we need ExecStatus (or, if everything else fails, a watchdog process). And now please finally answer my question from yesterday:
Now please tell me which way is smarter ;-)
Regards, Christian Boltz -- Registrierter Linux-Nutzer #239431 Linux is like a wigwam: no gates, no windows, but an apache inside. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29/12/11 17:40, Christian Boltz wrote:
Hello,
If you re-run the initscript and get the same set of
tempfile names, then something smells very fishy ;-)
Yeah, and FYI, these bugs are very common, and still exist on init scripts today.
Yes, and those services that need sharing have to run with PrivateTmp=false (which is the current default btw)
And there could also be attackers who inject files in a "private" /tmp/*/ directory after it has been created.
Really ? how ? the kernel won't let you do that, only the process started by systemd has access to those directories...
Instead, the "aa-status" script will give you all you need - including nice $? values. But: *** You have to run it! ***
yeah, and what's the problem documenting that the user has to run aa-status not systemctl status apparmor... to know what's going on ?
Not if apparmor notifies systemd that is unloading... sd_notify(3) may help.
Now please tell me which way is smarter ;-)
I would have to look what it does and figure it out. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/29/2011 4:06 PM, Cristian Rodríguez wrote:
On 29/12/11 17:40, Christian Boltz wrote:
What happened to the virtues of standardization? It's a downgrade to no longer be able to start/stop/query all major services using the same commands. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2011-12-29 at 19:11 -0500, Brian K. White wrote:
Absolutely. And the onus for doing the work is on those people proposing systemd as a better replacement, not on the rest of the world. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk8IQm4ACgkQtTMYHG2NR9VcZwCfc3e8uqeJQtewC2jc7GWno9F4 9aoAn0ejIbOVZbm1QnpCGY3zRbQC1zpg =D99K -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2011-12-29 at 21:40 +0100, Christian Boltz wrote:
Absolutely. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk8IQbQACgkQtTMYHG2NR9UNZwCfT4CKX4yIhG7A/jcWdWCbW9oH Uo4An0CCX7dShvQrVqwecsofn00pZY2t =PPBz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/12/11 20:54, Christian Boltz wrote:
You don't have to do that, both kernel modules and userspace have access to something called inotify or fanotify which can do exactly what you want. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
That was not the use case for ExecStatus The presented use cases were (a) services that have no master daemon process, but a set of processes. VM instances, or LXC containers were explicitly presented. And (b) services where the state can be changed by control commands without involvement of any daemon and thus there is no daemon that one can query for the current service status. In our customers' environment, both use cases happen quite often. You are quick to dismiss arguments, like in your *very* polemic answer to Christian's AppArmor arguments, without providing an explanation how these two use cases shall be handled with the current systemd framework; without introducing watchdog processes because upstream wouldn't implement them just for the sake of systemd. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Cristian Rodríguez <crrodriguez@opensuse.org> [2011-12-28 19:05]:
It's exactly this attitude which seems to be common among the cool kids at Redhat who know everything better. Turning a deaf ear to your customers' or users' preferences and use cases and trying to force something down their throat through technical means will invoke resistance and is ultimately doomed to failure. Either people will be begrudged by this arrogance and simply turn away or they will find creative technical means to work around the limitations with results which are usually not too pretty. It's sort of what currently happens with GNOME 3 and it's almost exactly the same when back in 2008 some Sun engineers declared the new IPS packaging system on Solaris a "no scripting zone", in fact the similarities in the sorrounding debates are striking. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/12/11 16:46, Guido Berhoerster wrote:
Someone has to take decisions and those cannot please everybody, currently it works this way: Those who do the work, take decisions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 28, 2011 at 4:53 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
Those who install the distributions do so as well. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/12/11 16:55, Claudio Freire wrote:
Yes, that 's the nice thing, for old school you have debian and slackware and gentoo.. All other distros either are planning to move to systemd, or already switched to it. and that's due the same thing, Those who do the work, take decisions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
Surely you meant that those who volunteer their skills and time get to decide. That is how a community-driven project ought to work, definitely. -- Per Jessen, Zürich (1.6°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 28, 2011 at 2:55 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
openSUSE currently has a 3-tier system officially; Board members users Unofficially it has: project management (Coolo, etc.) developers other contributors non-contributors The board seems to stay out of technical decisions, and the members only vote on the very occasional item. (ie. The members voted on the overall strategy recently.) Most decisions seem to be made by a adhoc combination of project management, members, developers, and other contributors. But the actual developers of the specific effort in question carry by far the most weight. Non-contributing users (those that install) seem to carry very little weight with the openSUSE project currently. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 28, 2011 at 5:03 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
Non-contributing users (those that install) seem to carry very little weight with the openSUSE project currently.
Really? Does the project go on if nobody installs it? Does the project's direction and goals stay the same if all servers move out of openSUSE? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Claudio Freire wrote:
Such as it is at the moment, yes. Even users who _do_ contribute seem to carry very little weight with the openSUSE project. The issue is that there is no such entity: "the opensuse Project". Like I wrote on opensuse-general not long ago, at best we have cooperation, certainly not orchestration.
Does the project go on if nobody installs it?
No it won't.
Does the project's direction and goals stay the same if all servers move out of openSUSE?
Does anybody care? -- Per Jessen, Zürich (0.9°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 28, 2011 at 6:19 PM, Per Jessen <per@opensuse.org> wrote:
Sad
Well, to put the discussion on-topic, from the comments everywhere, if systemd is pushed right now and sysvinit removed, lots of sysadmins will care. Especially sysadmins that value the overall openSUSE distribution, since it *is* valuable, and one misbehaving system, especially this critical system, can kill it on the datacenter. So yes, somebody cares. I wouldn't mind adopting systemd on a desktop, maybe enhancing systemd in the process, through bug reports and perhaps patches (maybe, if they're in the mood of accepting enhancements, which they don't seem to). On a server it's a different tune. So I wouldn't be surprised if datacenters rejected such a release.
Per Jessen, Zürich (0.9°C)
0.9°C? Really? Cool ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28.12.2011 21:06, Claudio Freire wrote:
fellas, please Isn´t the discussion off-topic enough? I´m not following the complete thread but it seems like both subjects are completely left behind in current discussion. It also "spams" our mailboxes to the edge, so please. could you please come back to topic again? thanks in advance, -- kind regards, -o) German Wiki Team Kim Leyendecker /\\ Documentation & marketing www.opensuse.org _\_v leyendecker@opensuse.org ===================================================== my GPG Key: 664265369547B825 | IRC: k-d-l Twitter: kim_d_ley | Wiki-Username: openLHAG openSUSE - Linux for open minds - get it free today! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Cristian Rodríguez <crrodriguez@opensuse.org> [2011-12-28 20:54]:
I don't dispute that developers are free to do whatever they want with their projects, I just pointed out that certain decisions and attitudes have the consequences that I described above. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Guido Berhoerster wrote:
Open source history is littered with such examples - gcc and egcs is one of the earliest I witnessed. -- Per Jessen, Zürich (1.1°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 December 2011 19:53:55 Cristian Rodríguez wrote:
So it seems you have set yourself up as king decission maker then .. -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 23:51 up 2 days 23:34, 4 users, load average: 0.03, 0.53, 1.27 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Peter Nikolic <p.nikolic1@btinternet.com> [12-28-11 18:54]:
So it seems you have set yourself up as king decission maker then ..
and you again resort to childish name calling. If you cannot present intelligent arguments and critism, just drop it. ps: no need to start with the personal mail, either. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 28, 2011 at 8:58 PM, Patrick Shanahan <paka@opensuse.org> wrote:
and you again resort to childish name calling. If you cannot present intelligent arguments and critism, just drop it.
Christian has already made very intelligent, to-the-point arguments that are being ignored. Name calling or ignoring are the only options left. I'm leaning towards the second one at this point. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Claudio Freire <klaussfreire@gmail.com> [12-28-11 20:05]:
or better :0 * ^From.*p\.nikolic1 /dev/null He doesn't bother with sentence structure, punctuation, spelling, profanity, accuracy, ..... Posts aren't worth the time to delete :^) -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/12/11 22:11, Patrick Shanahan wrote:
He doesn't bother with sentence structure, punctuation, spelling, profanity, accuracy, ..... Posts aren't worth the time to delete :^)
Glad to see I am not the only one that has been thinking about dropping his emails into the bit bucket. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 28, 2011 at 10:11 PM, Patrick Shanahan <paka@opensuse.org> wrote:
I just noticed there are two christians (one without 'h'). I was talking about Christian Boltz. In his latest post he outlined quite clearly the need for ExecStatus (which is only one missing function in systemd among several). He's been ignored since the RFC started, no objective technical counter-argument presented... ...it's getting tiresome. I want to influence the decision of dropping sysvinit, I don't want it dropped, but being ignored doesn't seem to be the way of getting there. So... 'tis been fun. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2011-12-29 02:11, Patrick Shanahan wrote:
What you say is true. However, there is a tiny bit of truth in what he says. Consider opinions statistically, the Gauss curve and all that. He is at the edge. I think that what he expresses coincides with what other users think but do not say, or say politely. I force myself to not respond to him, but I do not want to filter him out either. Just for that tiny tiny bit of truth :-) - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8DFSUACgkQja8UbcUWM1zXLAEAmvR9lhMOpCAi4Ev4+4+ILRzK jZ3pVCRd9cGQw14MtdcBAJbJnoLs49u4tZ9VpuopGVrJRMrIsb/7JX3PRKSlroCh =JZsn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 December 2011 23:58:03 Patrick Shanahan wrote:
Go rotate on a bluint article sonny .. -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 07:54 up 3 days 7:36, 4 users, load average: 0.37, 0.13, 0.04 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/28/2011 1:04 PM, Cristian Rodríguez wrote:
ExecStatus is ridiculous??? F YOU! Holy... ARGGGHHHH! What else is ridiculous? And why exactly are they ridiculous? They can be done some other way? And that way is better? I think some people have forgotten that Linux is a unix system. One of the features that makes unix so useful is the fact that it's made out of lots of individually simple, low level tools that can be combined into higher level systems. So, one thing systemd eventually intends to do is take over the job of cron and replace it. Hey, why run two processes when one is already running all the time anyways and could do the same job pretty easy along the way? That is a TERRIBLE idea. If that idea was valid then you could logically extend it to the point of having one process running the entire system. It might be cool and it might be good for some things but it wouldn't be unix and it wouldn't be 1/100th as useful. Maybe you should go work on some other kind of system like playstations or xbox's or phones and leave the general purpose unix-alikes alone. They are not a good fit for you. Yeah, asking for you to stop F-ing up the system that I have to live with is ridiculous. Except thankfully I don't have to live with it. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 December 2011 21:41:20 Brian K. White wrote:
That's all true. But Poettering and his groupies are not interrested in going the UNIX way at all. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 28.12.2011 15:49, schrieb Michal Kubeček:
So far, I haven't seen any (useful) feature that systemd would provide that couldn't be with much less effort achived without it.
Reliably(!) putting each service into its own cgroup. Reliably stopping a service and all(!) of its children. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 28, 2011 at 6:25 PM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Environment isolation (I've suffered environment leak when invoking initscripts myself). Maintainable system descriptions for the simple cases. Sane and explicit service dependencies (instead of an initialization order as in sysvinit, which sometimes makes it hard to guess why a service is started when it is started). Just to let people know I'm objective. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 of December 2011 18:30EN, Claudio Freire wrote:
Environment isolation (I've suffered environment leak when invoking initscripts myself).
Environment cleanup could be done in init scripts. But it should be done carefully as sometimes we need to pass certain variables to the daemons.
Maintainable system descriptions for the simple cases.
This is the problem: systemd seems to focus on the simple cases and ignore the rest.
We can have - and in fact have - sane and explicit dependencies. In fact, I consider the dependencies of type "service A needs B and C to run and possibly also D (if it is started at all)" much more sane and explicit than various features introduced by systemd. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 of December 2011 22:25EN, Stefan Seyfried wrote:
I replied to this already. This can be easily done with init scripts as well - with much less effort than has been invested into systemd transition (and without its harmful side effects). Moreover, these features could be optional as they are not always desirable - for instance, when restarting sshd, I certainly don't want to kill all its children. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.12.2011 08:50, schrieb Michal Kubeček:
Yes, by rewriting all init scripts. And keeping those patches forever... "easily" is also something I'd dispute here.
Of course there are services where it does not make sense - and for sshd it does not happen. But very often it is a must have feature. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 29 of December 2011 09:03EN, Stefan Seyfried wrote:
By "easily" I mean that amount of work needed for that would be a fraction of work needed to switch to systemd. As for the patches, we already put things like that into the init scripts and often provide our own version of init scripts. In fact, I haven't seen many packages where OpenSuSE (or SLE) uses upstream init script without any modification (and I'm not even sure there is any). Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.12.2011 09:22, schrieb Michal Kubeček:
And you think this is good? Reminds me of the old SuSE 8.x days when distributions differentiated themselves with pissing contests about who had more patches in the kernel... -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 29 of December 2011 09:30EN, Stefan Seyfried wrote:
Well, I would rather say "inevitable". And I don't think this is going to change much with systemd unit files. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29/12/11 04:50, Michal Kubeček wrote: for
instance, when restarting sshd, I certainly don't want to kill all its children.
That's why the sshd unit uses KillMode=process , it wont kill all children.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 Dec 2011 15:49:29 Michal Kubeček wrote:
I don't. So far, I haven't seen any (useful) feature that systemd would provide that couldn't be with much less effort achived without it.
I'm willing to accept this arguement if you can demonstrate that in sysvinit/scripts it for the features listed on the following page. http://0pointer.de/blog/projects/why.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 06 January 2012, Graham Anderson wrote:
We are talking about useful and useless features, like we wouldn't replace Vim by MS Word: http://i.imgur.com/usftZ.png cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2012-01-06 19:05:04 (+0100), Graham Anderson <graham.anderson@gmail.com> wrote:
Agreed. Michal, I don't think your statement is really fair, nor honest. systemd has a boatload of features that sysvinit cannot and will never provide. Those features are actually quite useful (starting on demand, cgroups, portable scripts, ...), and even provide potential for a lot of cool things that weren't really possible before (such as the D-Bus API). Sure, it's not 100% mature yet, and sure, as long as we haven't ported all our init scripts to systemd it's only half as useful. And I have also tried to understand how to write and install systemd stuff to start daemons and it definitely hasn't passed the "10 minute test". It definitely lacks better documentation, or I've been too lazy, I wouldn't exclude that from the equation :) The only thing we could honestly argue about is the time frame: whether it was too early to introduce systemd (too late to discuss that, IMHO it was fine ;)), and when we should dephase sysvinit, but there's another thread on that. Let's please try to refrain from seeing or stating everything as all black or all white, concentrate on objective pros and cons, and discuss this as engineers :) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf
On Friday 06 Jan 2012 19:59:30 Pascal Bleser wrote:
And this is the crux of the whole thread. There's too many unsubstantiated statements about the abilities (or lack thereof) of both sysvinit/scripts *and* systemd. Lets focus on the technical issues, and lets try to use facts, code, man pages and API docs to drive the discussion. In addition, the resources to support either of these init tech's must be front and center in the discussion. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 06 of January 2012 19:59EN, Pascal Bleser wrote:
It is completely honest. So far, I really haven't seen a systemd feature that doesn't fall into one of the following five categories: 1. Features traditional init scripts provide (e.g. parallel start). 2. Features implementable in traditional init scripts with effort much less than effort needed for systemd transition (e.g. cgroups). 3. Features systemd in fact doesn't provide (e.g. Cristian's claim that systemd can check whether unit files does what its author wanted it to). 4. Features for features, i.e. features with questionable usefulness (e.g. socket based activation). 5. Features I consider a bad idea (e.g. duplicating cron/at functionality). The only exception is faster boot. But (1) it is a bit questionable as big part of it is achieved by reintroducing the dirty trick of starting [kgw]dm as early as possible (or other forms of delaying start of services), (2) I don't consider it worth all the trouble systemd and transition to it brings.
I agree it was OK to _introduce_ systemd into OpenSuSE. But IMHO it was a great mistake to make it default in the state it was in 12.1. But unfortunately it is too late for this.
and when we should dephase sysvinit, but there's another thread on that.
The first question should always be "whether", not "when". And IIRC this thread started with exactly such proposition. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 December 2011 09:58:48 Michal Kubeček wrote:
I have to admit this is begining to look very like a case of self glorification for someone , Look i made them make the changes i want . And i for one am getting sick of it . Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 14:33 up 2 days 14:16, 5 users, load average: 1.14, 1.21, 1.16 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2011-12-28 09:27, Sven Burmeister wrote:
There is no denial that Cristian works a lot, and fine work. However, his tone in emails is often too /aggressive/ and sparks heated discussions. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8C8LoACgkQja8UbcUWM1z6mQD6A3v1zJU0uWw04ssOC4lSlo70 hBnAYhjgymF7rYnKZSYA/3gQdFSinkUD8//uhZbAgyArQFdvGgocskzCgvG7rWPr =6aGo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2011-12-27 13:57, Sebastian Freundt wrote:
[Bug 732934] chkconfig service on|off does not work with systemd. [Bug 732930] Systemd says network failed to start - which is false. [Bug 730051] "init 3" doesn't work with systemd and gdm - 12.1 RC2 [Bug 729757] Systemd is not documented. (in the openSUSE book) In the forum almost every day we have strange problem reports, and we say "try systemv at boot with F5" - and hey presto, it works. We ask the people to report them in Bugzilla, but being newcommers they don't, often. I can't help that, but the problems are real, nevertheless. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8C7n8ACgkQja8UbcUWM1xuRgD/UzisWOarfzqYt2q7pOIfE5gc F5OH5OT+VIERf4J1I8QA/ig0d76Dr1WmRUFhHR7bdmeaaMN9Bhjc/bVHWcXT1mqv =M/T/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 December 2011 21:15:32 Anders Johansson wrote:
+++11111 -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 07:42 up 1 day 7:25, 4 users, load average: 0.10, 0.08, 0.09 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/26/2011 1:00 AM, Rajko M. wrote:
logs are a thing that need to be acessible in minimalist and/or emergency situations. When a device or server is having a problem, that is not the time you want your diagnostic ability to rely on special tools that might not be available for any number of reasons. - not present on special boot image - broken library dependency - broken file format compatibility - not applicable for redirecting to special consoles, (serial, parallel, net, custom logger/watchdog script, custom loger/watchdog hardware, that might not be modifiable enough to build and install special binary log reader) Sure there are advantages to logging to a database. And they are conveniences that make the "everything is fine" case better at the expense of making the "everything is not fine" worse. The "everything is not fine" case comes along less frequently, but it _always_ comes along, and when it does, it's already bad enough without the complication of your diagnostic tools maybe suspect. On that day, you do not give a tenth of a rats crap for "increased efficiency" of being able to query logs from a db. Being able to sed/grep/awk etc from the file is valuable, and being able to read it directly with anything, even lowly cat or dd, let alone any of a bezillion editors/viewers that already exist everywhere on all platforms all cpus all versions since long before even the damned time_t epoch. Unless the format is human readable, then how do you really know that when you query it and get nothing, that it was really beacause nothing was there that matched and not merely that your human inscrutable special tool didn't simply fail to read the human inscrutable special file in some way? shells, editors, sed/awk/grep/perl etc do not suffer the same impossible burden of garanteeing to always work perfectly, because you can always look at a file directly using an uncountable number of other tools if any one is suspect. there are countless shells, cats dds vis etc... if I run some grep command on a text file and suspect the results, i can simply vi it or cat it or echo it through th shell itself, all 4 utils will not be broken at the same time and my eyes will not be subject to failure due to mere unexpected formatting. You can't demand "what situation will occur that you won't be able to use the log reader util? ". That is backwards thinking that leads to garbage non robust systems. You can't predict specific problems, or predict the impossibility of them. You can only design things so that, as much as possible, you avoid the _possibility_ of being without the ability to access something as important as syslog and dmesg, or fail to, and allow that possibility. "liklihood" isn't the important factor here. possible vs not-possible is. Even if you built the special log reader right into the kernel itself so it can't ever not be available & compatible, that still doesn't help all the examples of logging to devices that expect simple text. You want more efficient access to log data under normal circumstances? Feel free to _copy_ it to the db of your choice. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 December 2011 06:00:54 Rajko M. wrote:
You got some strange ideas and way of trying to corrupt what people say think we should name it the "Rodriguez method "
computer programs; just as stated in previous email:
What the jiggers are you on
I could care less about disk space i may have when i first started in the computer industry when 5Mb was a massive disk and no one would ever need more that 640Kb of ram but not now so that is invalidated Oh and we are talking of a Disk almost 2 feet in diameter needing a huge motor to wind it up to speed
Total bull fodder
Even more total bull fodder
No just i got the ability to see where you are trying to lead us and it aint a nice place
As i said darn windowsisation , We are supposed to be better than that but they way a lot of you are taking Linux you will assist in it's death
Pete .
-- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 09:18 up 9:01, 4 users, load average: 0.99, 0.78, 0.38 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Rajko M. wrote:
Don't forget the KISS principle. -- Per Jessen, Zürich (2.8°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/12/11 03:00, Rajko M. wrote:
"Darn windowization" :) Ideologists are in general detached from reality.
Indeed, dogma is not a way to move forward. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 December 2011 20:31:21 Cristian Rodríguez wrote:
Well sorry to say then but you are so far removed it is untrue You are doing a good job of turning a good workable software system into something that no one will want ie just another version of windows and YES i will keep Harping on about it because you are so darn blinded by your ideals you are unable to see past the end of your nose .. Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 07:58 up 1 day 7:41, 4 users, load average: 0.01, 0.02, 0.03 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
so... you expected... something in /var/tmp to be safe? I think it is simple to see the fallacy... Alin -- Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 19 November 2011 12:47:15 Alin Marin Elena wrote:
so... you expected... something in /var/tmp to be safe? I think it is simple to see the fallacy...
The key parts are "used to be safe" and "without warning". A responsible distributor doesn't risk his users' data in this way. m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Melchior FRANZ <melchior.franz@gmail.com> [11-19-11 08:15]:
conversly, a "responsible user" doesn't store data "expecting it to be save" in a system temporary directory, keyword *temporary*: Temporary \Tem"po*ra*ry\, a. [L. temporarius, fr. tempus, temporis, time: cf. F. temporaire.] Lasting for a time only; existing or continuing for a limited time; not permanent; as, the patient has obtained temporary relief. [1913 Webster] -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Melchior FRANZ <melchior.franz@gmail.com> [11-19-11 08:15]:
conversly, a "responsible user" doesn't store data "expecting it to be save" in a system temporary directory, keyword *temporary*: Temporary \Tem"po*ra*ry\, a. [L. temporarius, fr. tempus, temporis, time: cf. F. temporaire.] Lasting for a time only; existing or continuing for a limited time; not permanent; as, the patient has obtained temporary relief. [1913 Webster] ps: default settings on *my_box* do not include /var/tmp so you have made a change or have a local system problem..... -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 19 November 2011 09:03:57 Patrick Shanahan wrote:
ps: default settings on *my_box* do not include /var/tmp so you have made a change or have a local system problem.....
OK, thanks. I've occasionally put stuff under /var/tmp/$USER/ when I intended to throw it away shortly thereafter. Sometimes I kept it for longer, though. This has worked for years, so I don't think I've ever allowed openSUSE to clean out my /var/tmp/. This has happened for the first time now. To the apologists: I don't need lessons about what temporary means. It's just that until recently *I* was the one who decided how long "temporary" lasted. And I've never authorized anyone to delete my data. It's a matter of trust. Unjustified trust, as I know now. Won't make this mistake again. m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Melchior FRANZ schrieb:
I've occasionally put stuff under /var/tmp/$USER/ when I intended to throw it away shortly thereafter. Sometimes I kept it for longer, though.
I'm using ~/temp for that, which I think is way more reasonable than expecting anything in /tmp or /var/tmp to survive for any time. Robert Kaiser -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (44)
-
Alin Marin Elena -
Anders Johansson -
Anders Johansson -
Brian K. White -
Carlos E. R. -
Carlos E. R. -
Christian Boltz -
Claudio Freire -
Cristian Morales Vega -
Cristian Rodríguez -
Duncan Mac-Vicar P. -
Frederic Crozat -
Graham Anderson -
Greg Freemyer -
Guido Berhoerster -
Hans Witvliet -
jdd -
Joachim Schrod -
Joerg Mayer -
Jon Nelson -
KaiRo - Robert Kaiser -
Karl Eichwalder -
Ken Schneider - openSUSE -
Kim Leyendecker -
Lars Müller -
Linda Walsh -
Ludwig Nussel -
Melchior FRANZ -
Michal Kubeček -
Pascal Bleser -
Patrick Shanahan -
Per Jessen -
Peter Nikolic -
Rajko M. -
Roger Luedecke -
Roman Bysh -
Ruediger Meier -
Rüdiger Meier
-
Sebastian Freundt -
Stefan Seyfried -
Sven Burmeister -
Thomas Goettlicher -
Tim Edwards -
Vahis