On 02/28/2016 10:35 AM, Per Jessen wrote:

Billy.Zheng(zw963) wrote:

...

From logger command man:

...

...

logger - a shell command interface to the syslog(3) system log module

So, I want to use this command to write log to syslog.

following is a test:

$: echo 'some special log output' |logger

but, i could not found anything about my log in /var/log/.

...

From the man page:

logger [options] [message]

For your test to work:

$: echo 'some special log output' | xargs logger

Yes, that, and have the settings in whatever you are using as a log daemon configured appropriately :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 28-02-16 16:35, Per Jessen wrote:

Billy.Zheng(zw963) wrote:

...

From logger command man:

...

...

logger - a shell command interface to the syslog(3) system log module So, I want to use this command to write log to syslog.

following is a test:

$: echo 'some special log output' |logger

but, i could not found anything about my log in /var/log/.

From the man page:

logger [options] [message]

For your test to work:

$: echo 'some special log output' | xargs logger

Could you explain why this xargs is needed? (because it seems to work without it, on my system....) opensuse:~ # echo 'TEST1' | logger opensuse:~ # echo 'TEST2' | xargs logger opensuse:~ # tail -2 /var/log/messages 2016-02-28T17:14:22.807347+01:00 opensuse luuk: TEST1 2016-02-28T17:14:33.648455+01:00 opensuse luuk: TEST2 opensuse:~ # -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

That would suggest the OP just needs to look in the right places to find the messages logged.

Where is the `correct place' to found the `logger' command message on openSUSE 42.1? Thanks. Per Jessen writes:

Luuk wrote:

...

On 28-02-16 16:35, Per Jessen wrote:

...

Billy.Zheng(zw963) wrote:

...

From logger command man:

...

...

logger - a shell command interface to the syslog(3) system log module So, I want to use this command to write log to syslog.

following is a test:

$: echo 'some special log output' |logger

but, i could not found anything about my log in /var/log/.

From the man page:

logger [options] [message]

For your test to work:

$: echo 'some special log output' | xargs logger

Could you explain why this xargs is needed? (because it seems to work without it, on my system....)

Yep, you're right, according to the man page, logger defaults to reading from stdin when no message is specified and '-f' isn't used.

That would suggest the OP just needs to look in the right places to find the messages logged.

-- Per Jessen, Zürich (5.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland.

-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/01/2016 10:36 AM, jdd wrote:

Le 01/03/2016 19:29, Billy.Zheng (zw963) a écrit :

...

...

That would suggest the OP just needs to look in the right places to find the messages logged.

Where is the `correct place' to found the `logger' command message on openSUSE 42.1?

with Leap, use

journalctl

or dmesg

There are still some things that insist on finding /var/log/messages. I've been adding the "syslog-ng" package on 13.1 and 13.2. Does this still work with Leap? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

It's seem like dmesg is not work for `logger' command. could you explain how to view logger output with dmesg command ? I still not understood the difference about dmesg vs syslog. and when to use either of each. Thanks. jdd writes:

Le 01/03/2016 19:29, Billy.Zheng (zw963) a écrit :

...

...

That would suggest the OP just needs to look in the right places to find the messages logged.

Where is the `correct place' to found the `logger' command message on openSUSE 42.1?

with Leap, use

journalctl

or dmesg

jdd

-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/02/2016 02:17 AM, Per Jessen wrote:

Billy.Zheng(zw963) wrote:

...

It's seem like dmesg is not work for `logger' command.

could you explain how to view logger output with dmesg command ?

I still not understood the difference about dmesg vs syslog. and when to use either of each.

"man dmesg" - print or control the kernel ring buffer.

A syslog daemon writes all kinds of messages to persistent storage, e.g. logfiles.

I would add to that: syslog is a network protocol, any device on the network can send syslog messages to a logging host. I have my routers, my main router, my wifi router, any voip device all send their syslog messages to may main network host. The kernel ring buffer logs kernel activity, that is activity internal to a single machine, and to the kernel at that. As the 'logger' command illustrates, syslog is, with few exceptions, an application level protocol. The kernel ring buffer is solely about kernel activity. Yes, kernel activity my be triggered by application level or outside world actions; system calls or inserting a pluggable device such as a USB stick. In addition, there's nothing to say that the kernel can't send syslog messages (as it does when I insert a usb stick, as I've just demonstrated to myself with "tail -f /var/log/messages" and inserting a usb drive and getting the same info). However, to the best of my knowledge, syslog can't send to the ring buffer. Hmm: if syslog could send to the ring buffer that would be an attack surface; a rouge/hijacked network device could send syslog messages with buffer overflow to the kernel of a host. If that were possible we have a very serious structural flaw! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/02/2016 10:19 AM, Carlos E. R. wrote:

On 2016-03-02 15:58, Anton Aylward wrote:

...

Hmm: if syslog could send to the ring buffer that would be an attack surface; a rouge/hijacked network device could send syslog messages with buffer overflow to the kernel of a host. If that were possible we have a very serious structural flaw!

logger -p kern.info -t test "test message"

(not exactly what it would seem, though)

:-)

Hmm? It sends to the syslog daemon, not to the kernel. The "-p" just makes it appear to come /from/ the kernel. Now if you had an elaborated already subverted machine where there was a socket that gave access to the kernel, then you could send syslog messages into it, but if the machine was already corrupted to set up such as 'service' in the first place this is cake dressing. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Could you please tell me what version you use? Why 42.1 can not find /var/log/messages ? And, some service is not start correctly cause this file missing? Thanks. Luuk writes:

On 28-02-16 16:35, Per Jessen wrote:

...

Billy.Zheng(zw963) wrote:

...

From logger command man:

...

...

logger - a shell command interface to the syslog(3) system log module So, I want to use this command to write log to syslog.

following is a test:

$: echo 'some special log output' |logger

but, i could not found anything about my log in /var/log/.

From the man page:

logger [options] [message]

For your test to work:

$: echo 'some special log output' | xargs logger

Could you explain why this xargs is needed? (because it seems to work without it, on my system....)

opensuse:~ # echo 'TEST1' | logger opensuse:~ # echo 'TEST2' | xargs logger opensuse:~ # tail -2 /var/log/messages 2016-02-28T17:14:22.807347+01:00 opensuse luuk: TEST1 2016-02-28T17:14:33.648455+01:00 opensuse luuk: TEST2 opensuse:~ #

-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/02/2016 02:19 AM, Per Jessen wrote:

Billy.Zheng(zw963) wrote:

...

Could you please tell me what version you use?

Why 42.1 can not find /var/log/messages ?

And, some service is not start correctly cause this file missing?

Install a syslog daemon, as Carlos suggested - syslog-ng or rsyslog, for instance.

+1 If there is a basic *service* that cannot start because of the absence of /var/log/message please tell us what it is. I realise that there are going to be syslog scanning *applications* such as the venerable 'swatch' that are dependent on it, but that isn't a basic *service*. If there is some, for example, systemd triggered service in the basic distribution that depends on /var/log/messages rather than the journald mechanism, then yes it it a serious flaw. Please give details. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Billy.Zheng(zw963) wrote:

...

there is some, for example, systemd triggered service in the basic distribution that depends on /var/log/messages rather than the journald mechanism, then yes it it a serious flaw.

No, sorry, I have very poor knowledge about how system log is worked. What i need is just a simple way to add application log to one file.

My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file.

start_some_application |logger

Unless you have to write to a system log, surely "start_some_application

logfile" is easier ?

I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages.

You only get log written to /var/log/messages when you have a syslog daemon active. openSUSE does not by default install a syslog daemon. It's easy to add - "zypper in syslog-ng" or "zypper in rsyslog". I favour syslog-ng, it does everything I want it to with a minimum of config effort. -- Per Jessen, Zürich (1.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/03/2016 03:47 AM, Carlos E. R. wrote:

On 2016-03-03 04:27, Billy.Zheng (zw963) wrote:

...

No, sorry, I have very poor knowledge about how system log is worked. What i need is just a simple way to add application log to one file.

My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file.

If you want to write to a single file, just write yourself to it.

echo "some text" >> somefile

Yes, but don't make "somefile" /var/log/messages. Doing so will probably corrupt the proper message stream.

...

start_some_application |logger

Not the way to use it, IMHO.

Agreed. For example, "ssh -vvv" produced more information. But that's about a single user trying to connect, it is NOT a system activity, thus ssh -vvv 2>~/ssh.log makes more sense in this context than using syslog.

...

I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages.

This is not slackware. This is not the 20th century.

...

so, I don't know if some *service* is depend on /var/log/message.

No, nothing should depend on /var/log/message

I'd emphasise the 'should". There are probably many archaic programs that have not been dragged kicking and screaming into The Century of the Fruitbat, sorry, the 21st century, and still work by doing what amounts to "tail -f /var/log/messages" as did that old steadfast "swatch". http://linux.die.net/man/1/swatch But then swatch could be pointed at any file, including ~/ssh.log or included in a pipeline. So "journalctl -f | swatch" would work. I should note that the tool has been renamed to 'swatchdog' so as not to offend a Swiss watch company. it does not seem to have been updated to deal with journald directly. That being said, the kind of people who would have used 'swatch' in days of old probably now use the "Simple event correlator", https://sourceforge.net/projects/simple-evcorr http://simple-evcorr.github.io/ or similar. As it stands, journalctl is quite flexible. https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-vi... and http://0pointer.de/blog/projects/journalctl.html Which gets back to the question Why are you logging? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

I must say personally I feel "logger" is quite convenient, but you don't get to specify any alternative log file. I know my "logger" messages end up in both /var/log/syslog and journalctl. Personally I would prefer a more custom made or personal thing that logs only stuff that I want personally to be logged. And not system wide or in that system wide log file. Is there really not any simple way to achieve a modicum of features instead of outputting to a file directly? Of course I could simply log to syslog (using logger, I didn't even know it existed) but here is the thing: * if the log is voluminous, you would probably want something that is not into syslog, and that rotates * if the log is not voluminous, you won't need rotation as much, and maybe simple file redirect would be sufficient. So the moment you want more features, you probably have more log output, and when you have more log output, you probably don't want to log to syslog. Solution? :-/. Regards. Billy.Zheng(zw963) schreef op 08-04-16 16:51:

Sorry for my late reply. (disease, and missing lots of mail from thousands spam)

I read you reply carefully.

basically, the reason is, e.g. squid, though some like improper. because squid have own log builtin support when compile.

1. I want to use the last version squid in my VPS. so, i have to compile it myself.

2. I need a common startup script for squid to start. simply enough, I add one line in my crontab '@reboot /usr/local/bin/start_squid' `start_squid' is a bash script for start squid correctly.

3. i want to record log to file, for some net analysis. I am not a linux administrator, less experience for logger, i hope spend minimum cost to achieve a sysetm logger like service. function included following: - rotately automatically. - can be output real time if need.

I often read log when in programming development, so i think log is useful in this case.

The problem is:

1. What is the correct way to add my startup script log into journalctl or something else?

(suppose not use opensuse squid package startup script or systemd service. because I want this script to be use in any linux distribution, e.g: debian)

2. if use `ssh -vvv 2>~/ssh.log' way, should i must to add rotately function myself ? is there exist convenient way for this?

Thanks very much.

Anton Aylward writes:

...

On 03/03/2016 03:47 AM, Carlos E. R. wrote:

...

On 2016-03-03 04:27, Billy.Zheng (zw963) wrote:

...

No, sorry, I have very poor knowledge about how system log is worked. What i need is just a simple way to add application log to one file.

My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file.

If you want to write to a single file, just write yourself to it.

echo "some text" >> somefile

Yes, but don't make "somefile" /var/log/messages. Doing so will probably corrupt the proper message stream.

...

...

start_some_application |logger

Not the way to use it, IMHO.

Agreed.

For example, "ssh -vvv" produced more information. But that's about a single user trying to connect, it is NOT a system activity, thus

ssh -vvv 2>~/ssh.log

makes more sense in this context than using syslog.

...

...

I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages.

This is not slackware. This is not the 20th century.

...

...

so, I don't know if some *service* is depend on /var/log/message.

No, nothing should depend on /var/log/message

I'd emphasise the 'should". There are probably many archaic programs that have not been dragged kicking and screaming into The Century of the Fruitbat, sorry, the 21st century, and still work by doing what amounts to "tail -f /var/log/messages" as did that old steadfast "swatch". http://linux.die.net/man/1/swatch But then swatch could be pointed at any file, including ~/ssh.log or included in a pipeline.

So "journalctl -f | swatch" would work.

I should note that the tool has been renamed to 'swatchdog' so as not to offend a Swiss watch company. it does not seem to have been updated to deal with journald directly.

That being said, the kind of people who would have used 'swatch' in days of old probably now use the "Simple event correlator", https://sourceforge.net/projects/simple-evcorr http://simple-evcorr.github.io/ or similar.

As it stands, journalctl is quite flexible. https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-vi... and http://0pointer.de/blog/projects/journalctl.html

Which gets back to the question

Why are you logging?

-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Xen wrote:

I must say personally I feel "logger" is quite convenient, but you don't get to specify any alternative log file.

Yes, it writes to syslog, which by default is the systemd journal. If you want it written to a file, you need to install a syslog daemon and configure it to do that.

Personally I would prefer a more custom made or personal thing that logs only stuff that I want personally to be logged.

And not system wide or in that system wide log file.

Is there really not any simple way to achieve a modicum of features instead of outputting to a file directly?

Of course I could simply log to syslog

A log is just a file, no more, no less. The issue is how you write to it. Do you use the syslog() interface or do write directly to your own file. How you decide between them depends on what you're logging and from where, I would say.

* if the log is voluminous, you would probably want something that is not into syslog, and that rotates

* if the log is not voluminous, you won't need rotation as much, and maybe simple file redirect would be sufficient.

So the moment you want more features, you probably have more log output, and when you have more log output, you probably don't want to log to syslog.

Solution? :-/.

You don't seem to have presented us with a problem yet? Log to syslog, then have your favourite syslog daemon write it to your favourite logfile. If you need to rotate it, add a config to /etc/logrotate.d. /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Xen wrote:

Per Jessen schreef op 09-04-16 10:50:

...

Xen wrote:

...

I must say personally I feel "logger" is quite convenient, but you don't get to specify any alternative log file.

Yes, it writes to syslog, which by default is the systemd journal. If you want it written to a file, you need to install a syslog daemon and configure it to do that.

So I guess Carlos said you can have multiple destinations in your syslog daemon configuration. Otherwise it could mean you would need an additional syslog daemon for every program you want to log.

Yes, the default syslog-ng setup comes with at least 10 different destinations.

It also makes it impossible for any *user* to create logging without being the system administrator. All not very flexible and I guess.

As a regular user, I would just write to a file. syslog() is really meant for system users, not regular users.

I have said many times before perhaps: there is no middle ground between root and a regular user in a regular linux system.

Wouldn't privileged users fit in between root and regular users?

What if I write an application and I want to run it on a shell server on which I am just a guest. I want it to do logging within my personal user space. Now what?

Just write to a file?

Now I need to ship my application with its own syslog daemon and logrotate facility? Maybe actually log4j also does those things so I don't need anything for java applications.

Why would you need your own syslog daemon and logrotation?

But on Linux, I seem to be required to use existing daemons that are system-wide, I don't know.

Applications that don't fit into to the syslog categories/facilities should probably just write their own logs. Examples - mysql, squid, apache, vsftp, zypper, snmp, plenty of them. Perhaps you can describe the problem in some more detail, I'm not sure I've really understood it. -- Per Jessen, Zürich (8.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2016-04-09 at 19:24 +0200, Xen wrote:

Per Jessen schreef op 09-04-16 17:49:

...

Xen wrote:

...

Wouldn't privileged users fit in between root and regular users?

Those would be users that have specific sudo access right.

Other than that? And those users would be privileged to run commands as root, or just a few of those.

Once configured, the user only needs read access to the log files. ...

The only effort would be in creating the front-end interface (command line options, etc.).

Again, it is simply about having features but not having them located in the system, but closer to the application.

A user application has to write its own log files in his own user space. Completely under his control. Either he writes the code completely, or uses some library or system that already exists, such as that log4j. Many applications do this. He can instead use the system facilities, but then he doesn't have full control. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcJPo4ACgkQtTMYHG2NR9VWLACeKkWZUsmxmHMkgXNjie2dlD4H uqcAn3ype6JVVMUcwtjDXDC/V3DRYL5y =mPa9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen schreef op 09-04-16 23:52:

Xen wrote:

...

...

...

What if I write an application and I want to run it on a shell server on which I am just a guest. I want it to do logging within my personal user space. Now what?

Just write to a file?

The whole point was features remember.

No, I'm sorry, I was not aware. Features of what?

Are you being wilfully thick? I'm sorry for the word. I mean that you mention those features yourself down below.

...

...

...

Now I need to ship my application with its own syslog daemon and logrotate facility? Maybe actually log4j also does those things so I don't need anything for java applications.

Why would you need your own syslog daemon and logrotation?

[snip]

...

So the answer to your question is really simple:

to have those features as part of my program instead of as part of the system on which the program runs.

That still does not explain why you _need_ your own syslog daemon and logrotation.

Nobody ever needs anything. Do you need education? No, you can just keeping working the farm all of your life. Do you want education? Well maybe the answer could be yes. Maybe you want to get ahead in life. Could you use education? Well most assuredly so. But do you need it? No. So why not ask why someone would want it or could use it. The answer could be much clearer then.

...

There is a different between writing your own logs without any kind of functionality, and writing your own logs when an API for that is already present as part of existing libraries.

Not much of a difference, I submit. Whether you use your own write2log() call or that of an existing library does not make a real difference, except in the packaging (if you plan to distribute your code).

I did not compare two equivalent modes of functionality. I compared one mode of functionality that is meagre, because you need to write it yourself for your application yourself. The other one is rich, because other people have written it with the idea of being used by a lot of people. The difference is they call him king, the difference frightens me. What I mean is very simple, and you already know the answer. 1. Anything you write yourself you will have to write from scratch if you cannot reuse someone else's code. 2. This will take a lot of energy and is less efficient than reusing existing code if you agree with that code. You DO understand why libraries exist in the first place right? So not everyone has to constantly reinvent the wheel. I mean are you just purposefully being thick here? I mean pretending not to understand so you won't have to reach a certain conclusion? So no, the difference is not packaging, the difference is effort required to reach a certain level of functionality. That's WHY you use existing libraries. Now if those libraries don't exist, you have a problem. A certain feature in the system ecosystem is missing. And if existing syslogd and logrotate do not fit your purposes, then what? Are there situations where a programmer could /use/ application-level logging functionality instead of system-wide features? Definitely. Why not? Why wouldn't there be? After all, you've notice that this is the raison d'être of Log4j in the first place. Why would it exist if there was no use for it? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen schreef op 10-04-16 10:19:

...

The difference is they call him king, the difference frightens me.

What I mean is very simple, and you already know the answer.

1. Anything you write yourself you will have to write from scratch if you cannot reuse someone else's code. 2. This will take a lot of energy and is less efficient than reusing existing code if you agree with that code.

In principle this is absolutely true, in practice for a write2log() call, less so. Unless that call was part of a framework I wanted to use in my application anyway, I would not bother. It would take me less time to write my own than to learn how to use a foreign one.

Probably, but that depends on how complex those other ones are, and whether you can use it with a few simple command calls. For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).

...

You DO understand why libraries exist in the first place right? So not everyone has to constantly reinvent the wheel. I mean are you just purposefully being thick here? I mean pretending not to understand so you won't have to reach a certain conclusion? So no, the difference is not packaging, the difference is effort required to reach a certain level of functionality. That's WHY you use existing libraries.

Would you like to be a little less condescending?

Most of what you write is condescending to begin with. And I apologized for the word thick, I just don't know how to express it.

...

Now if those libraries don't exist, you have a problem. A certain feature in the system ecosystem is missing.

If they don't exist, you have no option but to write them yourself. I don't see a problem here.

The question was whether they exist. Logrotation and asynchronous writing and all of that is not that easy to implement. Sure, if you spend a few hours to a few days on it, sure you might have something. The whole purpose of me asking was to help the OP (and myself) to see if something might not be missing here. If every application writes its own logging framework, that's a lot of wasted effort. Apparently you want me to start exploring the source of e.g. squid to see how it does it. I would think people would know about these answers.

...

And if existing syslogd and logrotate do not fit your purposes, then what?

1) invent your own wheel or, 2) change your purpose to suit the wheels at hand

Yes, you're being thick. The question was clearly intended to find a solution that did agree with the purpose. Changing your purpose is like changing the question and reason for asking, and as such it means not getting an answer. Writing it yourself means spending an amount of time you were trying to avoid to see if something else did not already exist. I mean you don't have to answer questions you don't understand by assuming or insinuating that the person asking the question is somehow too stupid to come up with these answers himself. How do I view a webpage? 1. Write an operating system. 2. Write networking software. 3. Write a desktop GUI 4. Write a web browser Now you can view a webpage. (Facepalm). I KNOW that I could write any piece of missing functionality myself, if I had the time. I KNOW I can create my own logging framework and market or distribute it. If I had the time, the ability, the purpose, and the convenience. I KNOW that that would be a solution. But if a solution currently does not exist it is also because of people who cannot understand that anyone would want it. It's like there only being two kinds of apples on the market: very small ones, and very big ones. And then someone comes and says "why are there not any medium ones?" And people answer "Why do you need a medium one? You can just eat lots of small ones right? Or chop a big one in half?" This is the problem with most Linux people, they cannot conceive of anything new coming into being. When you say "why are there no medium apples?" they cannot understand why anyone would want a medium apple. When you say "why is there no logging framework?" they say "you can use the big one or the small one, right? Why do you have a need for a medium one?" Maybe "why" is a meaningless question, but I did not really ask that. I asked whether anything of the kind existed, and tried to explain the reasons why. "And if existing syslogd and logrotate do not fit your purposes, then what?" This question was clearly intended to open up the space where solutions could be found. Not a denial of any kind of answer with a collapse into non-creative "use what is available or do it yourself" answers. The whole point was to inquire into what more could be available. Such inquiries can transform into a creative approach, but you don't start designing your own meant-for-broader-use system either unless and until you have explored the existing landscape. You will first want to know if anyone else has done it, before you start doing it yourself, mostly. "Use what is available or do it yourself" is not the kind of answer that contains any information. The answer is so generic that it applies to everything, or rather, that it does not apply to anything. I was not asking for the well-traveled road, as we say in Dutch. I was curious whether something did actually not really exist. Then when you (Per) asked why I would even want it, I tried to explain.

...

Are there situations where a programmer could /use/ application-level logging functionality instead of system-wide features? Definitely. Why not?

That what I keep saying. It's called write(). see "man 2 write".

This is about as condescending as you can get without using explicit words for it. You really feel the need to tell someone about the most primitive system call to write text to a file???? Insulting people or someone by pretending, assuming or insinuating that person would not have been able to come up with that himself? This is what you do constantly Per. You give answers I do not need because apparently you do not understand that I am looking for something more. It is like saying "how can I write a thesis about global economies and their interrelationship?" and you say "grab a pen and paper". Clearly the person did not inquire into that sort of information. You are not doing that person a service okay. You also don't need to tell me what grep is or what a file redirect could be. You also don't need to tell me how to use a keyboard to write commands. I was asking for a certain kind of solution and whether it existed or not, and I expressed some incredulity that apparently in fact it doesn't -- or you people would probably know about it (but I can't be sure). I don't need to be told that I can change my purpose or write the thing I need from scratch. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward schreef op 11-04-16 01:15:

On 04/10/2016 06:55 PM, Xen wrote:

...

For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).

And what 'extra' functionality do you think it SHOULD have? And how would that make it easier to use?

Can you be specific, please.

I already explained at the beginning: In short: a logging library or program (for a shell script, you could not use a library, you need to have a command line tool). That could do what logrotate and syslog do, without requiring logrotate and syslog. Logrotate is not actually an administrator-specific tool. And there are things like user crontabs. But setting up the target of e.g. "logger" implies having sysadmin access or someone that can do it for you, because it depends on syslog, which cannot be configured by a user in any way. If I write a program that needs to be portable from system to system and that requires local logging to take place, Then I need to be able to package its logging system together with the application. Now Log4J does that, but supposing not everything I do is Java. I will need a logging library of certain functionality that cron, logrotate and syslog already provide. The very same features: * rotation * gzipping of old logs, possibly deletion of very old logs * possibly asynchronous writing, but not very important at this point. * support for different levels (info, debug, etc.) And yes I can write this, I was just curious whether it already existed. Maybe I should just repackage cron, logrotate and syslog as user-level programs/daemons ;-). You know, have your program have a /bin directory that contains those programs, just they run as your (program) user and may have different names and they do not need access to the full / trees. So your program could be packaged in a : /bin /etc /lib Of its own, and the programs you supply together with the program use that. Then you simply write to your own daemon instead of the system-wide daemon. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/12/2016 07:32 AM, Carlos E. R. wrote:

Wait. The specific question here is what do you find missing in "logger". Remember that logger requires a syslog daemon (can be systemd journal), with all the wistles, including rotating.

You are talking about a tool that does not exist or that we have not found, to log to file by users, not "logger".

So, the question: what do you find missing in the existing logger, aimed at syslog?

Indeed! Focus, focus, focus. Xen, you are good at rambling discussions of perceived shortcomings, but you lack specifics, both about what the exact shortcomings are and actual suggestions about remediation. Rather than rambling, get down to specifics. Give a LIST of the shortcoming without the rambling discussion. The, for each item on that lit, suggest a remediation, again without rambling. Please, no rambling. Focus, Focus, Focus. The ramblings do not add to your case, they defocus your arguments and end up in the TL;DR bin. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/12/2016 07:41 PM, Xen wrote:

Carlos E. R. schreef op 12-04-16 13:32:

...

On Monday, 2016-04-11 at 21:06 +0200, Xen wrote:

...

Anton Aylward schreef op 11-04-16 01:15:

...

On 04/10/2016 06:55 PM, Xen wrote:

...

For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).

And what 'extra' functionality do you think it SHOULD have? And how would that make it easier to use?

Can you be specific, please.

I already explained at the beginning:

In short:

a logging library or program (for a shell script, you could not use a library, you need to have a command line tool).

Many CLIs - zypper is a good example - are libraries with wrappers. The issue is the functionality, not whether it is a library or a CLI wrapper for that library. Its this kind of fuzzy thinking, last of a precise REQUIREMENT and specification that has taken this into a rambling and unhelpful discourse. If you can't see that very basic aspect of programming, that even the CLIs are made up on top of libraries that can be used elsewhere, then its "abandon hope and discard this thread".

...

So, the question: what do you find missing in the existing logger, aimed at syslog?

I have no interest in a logger that can only log to syslog.

You must be, as Whitman observed, vast, vaster than the rest of us here, since you contradict yourself. What functions you do describe can be carried out by the logger libraries and configuration files. A visit to Perl's CPAN will give some edification in this area too.

Although, of course, you could run your own user-created syslog daemon that you configure and specify as a user, and then you could log to it using -n and -P tags/flags.

I don't know why you want to make things so complicated. The already existing rsyslog mechanism not only supports programmability and templates, but listens on sockets. All that is specified in config file. You can have up to 50 concurrent sockets, and thanks to the programmability of rsyslog, your custom config file can turn these on and off according to your own programatically defined needs. At this point 'facility' and 'priority' loose their classical meaning and are just additional parameters for your custom tool. They can be used to trigger specific 'templates'. The important thing here is that a "daemon' listens on a specified socket. Which one? well that's what the config file is for.

As to Anton, you are trying to derail the discussion. I never had any interest in logger as a real solution unless I can tweak it to my usage.

My point is that you can 'tweak' it; you should know that if you'd actually RTFM, and if you had a clearer idea of what you were trying to achieve, rather than just denouncing Linux as you seem to keep doing. The people who designed many of these components had a good vision, and all you are doing with this argumentative approach and dodging around is showing that you have (a) failed to do proper research into the matter and (b) are committing the error of fuzzy thinking by not clarifying what you actually want and playing stupid "yes-but" games. There is no malice, just an emergent property of the fuzzy thinking.

I have stated numerous times:

* Functionality akin to logger/syslog/logrotate/cron that I can control completely as a general non-privileged user on any system.

If you had RTFM and experimented a bit based on what is documented you'd know that is possible.

It does require starting the daemon as your program (script) starts, and shutting it down when you finish, which is a bit weird for scripts, but perhaps doable for real programs. It is really only necessary (theoretically) if you require asynchronous logging though.

I don't see an objection or problem here. There are many database services that don't need a "daemon" beyond the lifetime of the user running the application. Back in the days of email carried by UUCP there was no continuously running "email daemon". We accept the continuously running email daemon today becuase it need to carry a lot of traffic, but there is no reason wht it *has* to be continually running. A low volume site could have a "sender" that is only triggered by a user pressing "send" causing another program to execl. The XinetD could have a configuration for a receiver that is only spawned when someone comes knocking on port 25. In the days before we had CUPS (or even is SVR4 predecessor) there was no line printer daemon, just a driver programme for a printer hanging off a tty port :-) It lived only as long as it took to drive the line printer.

You could also consider that some system administrator might not like you running something like that :p.

I can't see why. What's wrong with creating your own named pipes? (aka sockets). Why do you think 'mknod' is in '/usr/bin/ and not /sbin/? Its so ordinary users cam run mknod -p <filename> In fact FIFO mode is the only truly portable and user available mode of mknod. See the various man pages for the reason for that. Of course you may prefer 'mkfifo'

I don't even know what system I have in mind. If I just use java, and maybe some java-python plugin (jPython?) I won't even be dealing with scripts.

The boundary between what is a script and what is 'just' a program when it come to interpretive languages is fuzzy. Java and Python you can clearly save the intermediate code. Perl and Ruby are a bit ambiguous in this regard. The Bash shell is very unambiguously what is termed a 'throw-away compiler-interpreter' (nomenclature due to P. J. Brown of Oxford and Canterbury) in that it build the parse tree but doesn't retail the source, but the parse tree is inaccessible. (Of course there are hacked versions where that's available for debugging purposes, but such are outside the scope of this.) Yes, you can view Java/Python as a 'throw-away' where the source is thrown away but the parse tree has been complied to a reloadable module, where as the similar module doesn't exist for Bash. They are still both interpreters and are still both scriptable.

I cannot imagine requiring async logging for something that is nothing more than a (big) shell script.

Right now you can't :-) But after you've used the setup for a year and published it you, or someone else, will end up with that as a requirement. Maybe you're doing a client/server thing like SSH and need to log both ends.

What remains is real Linux programs (I mean C/C++) and I have no intent really of writing any yet. Also firing up daemons of your own might not be very nice.

*sigh* I can't see why its any more "not nice" than any other form of non-trivial shell scripting (or scripting in Perl or Python or Ruby).

If I wrote anything for Linux myself it would probably be Python at first. I'm sure there is some logging library for it that I could use.

I use Perl and Ruby and there is for both; I can't imagine Python is crippled and doesn't have one.

For instance, you could imagine a "user" set of programs where all executables are just symlinks. Say what would amount to a /usr/local/bin but all files are symlinks to the real programs.

Ahm, I can do that already. I can unpack RPMs into ${HOME|/bin and ${HOME}/lib. I do this at one of my ISPs where I need a later version of Ruby and its libraries for a RubyOnRails application I have. I know it can be done, so please don't tell me it can't be done. I just have to have my own version in the $PATH and ${LD_LIBRARY_PATH} ahead of the system defined values.

Then you could scope the rest of the system to hide much from the user and only show what she wants to see.

Something like that, I don't know.

I do. BTDT. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/12/2016 09:33 PM, Carlos E. R. wrote:

On 2016-04-13 03:18, Anton Aylward wrote:

...

On 04/12/2016 07:41 PM, Xen wrote:

...

I don't know why you want to make things so complicated. The already existing rsyslog mechanism not only supports programmability and templates, but listens on sockets.

He wants it to be all run and configured as plain user, not as root. It can not be the system syslog.

Indeed, and it need not be. Yes, systemd (or sysvinit if you are still using that) runs the SYSTEM syslog daemon. But there is no reason you can't start another instance of "a" syslog server with your own defines config file as a user. In fact the model I suggest is there already, read the script "rsyslog-service-prepare" which sets up the possible additional sockets for the system level rsyslog to listen on. Of course 'out of the box' that set is empty for there is only the socket in /var/run/rsyslog since there are no more defined in /etc/config/syslog. Yes a user side daemon would need its own start up script and start up parameters and config file. So what? Strictly speaking its only necessary to have your (or the system level) rsyslog daemon read from a file, the imfile module and its parameter list, which is amazingly flexible does this. You can list multiple files each with their own characteristics. Some may simply be read once; some mail be read as 'tail -f'. And of course some can be pipes :-) In general, see http://www.rsyslog.com/ Specific to sockets http://www.rsyslog.com/doc/v8-stable/configuration/modules/imuxsock.html http://www.rsyslog.com/doc/v8-stable/configuration/modules/omuxsock.html Also note a thread that I haven't explored, the ability to have rsyslog use arbitrary external programs, even user defined scripts: http://www.rsyslog.com/doc/v8-stable/configuration/modules/omprog.html You'll see in that a note: "... especially if it is not running as root...". Now why would it not be running as root? The system-level (systemd spawned) server runs as root, so the alternative must be a user initiated server. As I said, this is a very flexible tool. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-11 00:55, Xen wrote:

Per Jessen schreef op 10-04-16 10:19:

...

In principle this is absolutely true, in practice for a write2log() call, less so. Unless that call was part of a framework I wanted to use in my application anyway, I would not bother. It would take me less time to write my own than to learn how to use a foreign one.

Probably, but that depends on how complex those other ones are, and whether you can use it with a few simple command calls.

For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).

What else do you want it to do? I use it often in scripts, that's what it is for.

The question was whether they exist. Logrotation and asynchronous writing and all of that is not that easy to implement. Sure, if you spend a few hours to a few days on it, sure you might have something. The whole purpose of me asking was to help the OP (and myself) to see if something might not be missing here.

If every application writes its own logging framework, that's a lot of wasted effort. Apparently you want me to start exploring the source of e.g. squid to see how it does it. I would think people would know about these answers.

I gave you a dozen examples of programs you could examine. Yes, if I'm going to create a complicated application, certainly I will examine code examples I may reuse!

Writing it yourself means spending an amount of time you were trying to avoid to see if something else did not already exist.

I use my own log often enough in my scripts. As simple as a simple function that calls "echo" with a timestamp and a file destination, that's all. I don't see the difficulty... You said, I think, you coded in Delphi. Then have a look at Lazarus, it is a multiplatform remake of Delphi. Just write to a text file with a cache. Or look in the examples to find something else... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcK7eQACgkQja8UbcUWM1wz3wD8CgUaGnOHzaPpI2/kLiknxi/Y 9XuCrKCxSlUveTr9nNUA/0fXteLE+cuHFh1Olb2Rs6Re57uyZS2m1+p++E3f/VVR =GYRY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. schreef op 11-04-16 02:20:

...

For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).

What else do you want it to do? I use it often in scripts, that's what it is for.

Well of course it writes to the system syslog. I want something that can write to a file without having to configure it in syslog.

...

If every application writes its own logging framework, that's a lot of wasted effort. Apparently you want me to start exploring the source of e.g. squid to see how it does it. I would think people would know about these answers.

I gave you a dozen examples of programs you could examine. Yes, if I'm going to create a complicated application, certainly I will examine code examples I may reuse!

Well okay. But the reason for me asking was to discover whether that be necessary to begin with. See if you use log4j, there is no need for you to do anything. You can use it to log synchronously, asynchronously, to any database, to a syslog server, in any format you want, etc. etc. etc. But you understand.

...

Writing it yourself means spending an amount of time you were trying to avoid to see if something else did not already exist.

I use my own log often enough in my scripts. As simple as a simple function that calls "echo" with a timestamp and a file destination, that's all. I don't see the difficulty...

Of course, but the inquiry was about having more advanced features that syslog also provides. Without requiring syslog. If there is something easy to use, then I might be able to more easily incorporate it into my own scripts. Makes them less portable, but so be it. I have seen one such script I must say. I came across it when I was researching scripts that provide a more complete rsync experience. One of those scripts used its own logger script that was quite complete, I believe. Not sure though. Maybe I was mistaken and it just used the regular logger, which I did not know about.

You said, I think, you coded in Delphi. Then have a look at Lazarus, it is a multiplatform remake of Delphi. Just write to a text file with a cache. Or look in the examples to find something else...

No my friend, I do not need help into very basic logging principles, I was just inquiring whether something more fully developed would exist for Linux that was not the triade of syslog/cron/logrotate. If most people generally just go with syslog/cron/logrotate then no one might ever have found a need (or desire) for it. However if you say that many programs do bring their own system, then maybe we're missing something. Basic rotation would not be hard to implement in your own script, I concur, but it needs the work in any case and usually (thus far) I am not willing to put that much work into it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Xen wrote:

I want something that can write to a file without having to configure it in syslog.

At some point you'll have to explain why write() doesn't suffice for that :-)

...

...

If every application writes its own logging framework, that's a lot of wasted effort. Apparently you want me to start exploring the source of e.g. squid to see how it does it. I would think people would know about these answers.

I gave you a dozen examples of programs you could examine. Yes, if I'm going to create a complicated application, certainly I will examine code examples I may reuse!

Well okay. But the reason for me asking was to discover whether that be necessary to begin with.

See if you use log4j, there is no need for you to do anything.

You can use it to log synchronously, asynchronously, to any database, to a syslog server, in any format you want, etc. etc. etc. But you understand.

Your question could perhaps have been better written as "is there a non-java equivalent of log4j?" -- Per Jessen, Zürich (9.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Xen wrote:

Per Jessen schreef op 10-04-16 10:19:

...

...

The difference is they call him king, the difference frightens me.

What I mean is very simple, and you already know the answer.

1. Anything you write yourself you will have to write from scratch if you cannot reuse someone else's code. 2. This will take a lot of energy and is less efficient than reusing existing code if you agree with that code.

In principle this is absolutely true, in practice for a write2log() call, less so. Unless that call was part of a framework I wanted to use in my application anyway, I would not bother. It would take me less time to write my own than to learn how to use a foreign one.

Probably, but that depends on how complex those other ones are, and whether you can use it with a few simple command calls.

For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).

logger consists of about 3 lines of C code: openlog(facility); syslog(prio,text); closelog(); My imagined write2log() might be roughly the same: f=open(file,O_APPEND|O_WRONLY); write(f,buffer,snprintf(buffer,sizeof(buffer),"text", vars)); close(f);

...

...

Now if those libraries don't exist, you have a problem. A certain feature in the system ecosystem is missing.

If they don't exist, you have no option but to write them yourself. I don't see a problem here.

The question was whether they exist. Logrotation and asynchronous writing and all of that is not that easy to implement. Sure, if you spend a few hours to a few days on it, sure you might have something. The whole purpose of me asking was to help the OP (and myself) to see if something might not be missing here.

Okay, although there's virtually always room for improvement, writing to a log is a fairly simply thing in 99% of cases. The last 1% - I'm not sure what they might be, maybe it's about performance or response time when writing thousands of lines per second or some such. You or the OP would need to add your input here.

If every application writes its own logging framework, that's a lot of wasted effort.

Absolutely. I don't think that is what happens either. I think most applications use something like this: write(f,buffer,snprintf(buffer,sizeof(buffer),"text", vars)); possibly with a nice macro WRITE2LOG(prio,format,vars...).

Apparently you want me to start exploring the source of e.g. squid to see how it does it. I would think people would know about these answers.

No, actually I was interested in understanding which logging features you are missing. [snip - gobbledegook]

But if a solution currently does not exist it is also because of people who cannot understand that anyone would want it.

Often there is no solution when there is no problem. Sofar I believe you have failed to describe the problem. Or maybe I'm just too thick.

"And if existing syslogd and logrotate do not fit your purposes, then what?"

This question was clearly intended to open up the space where solutions could be found.

How can anyone propose a solution when you have not presented a problem?? All you said was "existing syslogd and logrotate do not fit my purposes". Please explain your purposes, otherwise we'll never get anywhere. -- Per Jessen, Zürich (6.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. schreef op 09-04-16 19:08:

There are 7 user facilities.

But the user cannot configure the target on his own right, he needs the cooperation of the system administrator.

...

What if I write an application and I want to run it on a shell server on which I am just a guest.

I want it to do logging within my personal user space.

Do it yourself, with write statements in your program.

To the syslog daemon?

Or use journalctl, which allows for user logs, I think (I don't know for sure, I haven't tried).

Buh. That is like going through Russia in order to arrive at Germany (starting from the Netherlands) ;-). That's my whole issue with SystemD. Instead of going straight at the easiest and most sensible solution, you first have to pay 6 intermediaries for their reference.

...

Just the way it would happen for me I guess. In the meantime I keep writing my own logging system (more or less) in every bash script I write, because I require different levels etc.

Yes, that's what everybody does.

Well that is not a very happy situation is it?? Including stuff in Bash scripts is annoying, otherwise I would already have found myself a logger script probably. Eventually I will though. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. schreef op 09-04-16 19:55:

On Saturday, 2016-04-09 at 19:32 +0200, Xen wrote:

...

Carlos E. R. schreef op 09-04-16 19:08:

But the user cannot configure the target on his own right, he needs the cooperation of the system administrator.

Yes, that is so.

There are many systems where this is not possible. Webhosts are one -- even webhosts running shell servers and the ability to execute programs.

...

...

Do it yourself, with write statements in your program.

To the syslog daemon?

No, to files.

...

...

Yes, that's what everybody does.

Well that is not a very happy situation is it??

Why not? :-o

It is the same in any computing system, as far as I know.

...

Including stuff in Bash scripts is annoying, otherwise I would already have found myself a logger script probably.

Eventually I will though.

It might be another process. I don't know well how to communicate data from one process to another, without using the disk somehow (named pipes?)

From the other email:

A user application has to write its own log files in his own user space. Completely under his control. Either he writes the code completely, or uses some library or system that already exists, such as that log4j. Many applications do this.

He can instead use the system facilities, but then he doesn't have full control.

So the question really is: where is that library? Is there such a library? Apparently and probably not because everyone believes we should use syslogd. So what is really going on in this thread is stating a use case that is not catered for. What does not exist is application-level logging facilities for Linux. There is no reason whatsoever that logging, asynchronous logging, or logrotation of any kind, should be a thing limited to the system administrator. There is also no reason why the system administrator would admonish against it, since this feature is nothing special at all. Consequently, there is no real reason why it would require administrator intervention, but then, a regular user normally cannot install programs either. (Except by compiling himself/herself). That's really the whole issue. It is black and white. The "user" that installs programs does not exist. On public shell servers, users always run programs. They often install their own programs. The user "space" is not really well defined or understood in Linux. There is no middle ground. Something that is readily availabe in Java does not even exist in Linux. Maybe it does. That's why we're asking right. I am deeply annoyed by the amount of times I need root access. This is most strongly so with e.g. packages or applications that get set up system-wide, but that do not belong there (such as wikis). On Debian et al, for instance "DokuWiki" is installed in /etc/dokuwiki, /var/lib/dokuwiki, and /usr/share/dokuwiki. The main package as per the maintainer combines this all into one. Now it runs as a package on a system and it is unmaintainable. For instance: /userstyle.css/ is a file that needs to be edited by the system administrator in /etc/dokuwiki. Now I need to be ROOT to change a stylesheet of a small wiki. If I remove the package and install it in /usr/local (for instance) I lose the benefits of the Debian package configurator. It runs in conjunction with Apache (or Lighttpd) which is nothing more than a few apache entries (probably one file in the required directory) but that's really the only thing you need administrator access for. There is no reason the application itself (/usr/share/dokuwiki) or its main configuration (/etc/dokuwiki) or its database (/var/lib/dokuwiki) should run under root. The program itself runs as www-data, but that is a group. And a user. But you cannot login to that user or work as that user. Personally I feel we need a concept of user-controlled filesystem space (outside of FHS in that sense) being managed by group rights where files are group writable by default and inherit group ownership upon creation. The g+s sticky bit. The setgid bit. This area would be maintained by "staff" group and would not impede on the operation of the system in itself. In a certain sense, that would also require a group of ports that is not privileged (1-1024) but semi-privileged (1025-2048). This "in between" just does not exist, wherever you look at it. It is either user or root. Or the program gets started as root and then relinquishes privs to become a decicated user for that program. Why not a "group" layer in between? Why not a class of users that can install programs but only in what would be considered /usr/local? It might not even be difficult to create packages that could be both installed system-wide, and as a local thing. But the concept would need to be introduced. For instance, on Debian the program "apt-file" will create a system-wide cache when run as root, or a user-created cache when run as a user. If we had a platform for this, it would be very easy. This in turn would turn the installation of many programs into something that would not even require root privs (possibly). I mean I have been doing this since like forever. I would create substed volume letters based off off trees such as C:\Programs\Games would become E:, for instance. I always created my own area. Anyway, Need to go. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. schreef op 10-04-16 01:34:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2016-04-09 22:19, Xen wrote:

...

Carlos E. R. schreef op 09-04-16 19:55:

...

So the question really is: where is that library?

Is there such a library? Apparently and probably not because everyone believes we should use syslogd.

You forget that there are many applications in Linux that use their own logging systems.

Which one? Or do they all reinvent the wheel?

...

The user "space" is not really well defined or understood in Linux. There is no middle ground. Something that is readily availabe in Java does not even exist in Linux.

Well, no. Linux, or rather Unix, was designed with a single admin with full powers. It is not that simple to modify this basic idea.

I know, but I'm trying anyway. Cause the current system causes groups to not be used, and causes problems for me. So I need to get around it anyway. At this point I still need to create a diff of changes I made against an older version of DokuWiki, then upgrade the package (on my NAS) and reapply my changes and get it working again. Then find a way to actually use the newest version so I am current with the developments. Then, try to decide how I am going to do it in my debian host....... But I'm definitely just going to get rid of the package probably and move it into its own directory where everything is tied together instead of existing in 3 trees. Then I will try to enforce group-writability on the data and see how that works out.

On the other hand, it is quite feasible for the designer of any application to allow it to be administered by another user.

You mean with a setuid program or something of the kind? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-04-10 01:55, Xen wrote:

Carlos E. R. schreef op 10-04-16 01:34:

...

...

Is there such a library? Apparently and probably not because everyone believes we should use syslogd.

You forget that there are many applications in Linux that use their own logging systems.

Which one? Or do they all reinvent the wheel?

As I'm not a Linux programmer, I can't say if a library for the purpose exists or not. For example, procmail uses its own system. At the start of the config, you define where: LOGFILE=$HOME/procmail.log Another one: fetchmail. At the start of the config you tell it whether to use syslog or not: set syslog alternatively, use "nosyslog" and "logfile". Another. Amavis-new. I see this in the configuration (there is no man page for a quick search): $do_syslog = 1; # log via syslogd (preferred) Another one: YaST. Or zypper. That makes two. Wait! Looking at /var/log/ I notice some more: apache, consolekit, apparmor, audit, cacti, cups, gdm, lightdm, mysql, nagios, ntop, sa, samba, smpppd, snort, vmware... I notice them because they have their own log directories. There are a few more that use distinct files under /var/log/, without a separate directory, but differentiating which are used by syslog and which not is a bit more difficult. The first one is now extinct: SaX. But Xorg is not. There are some that log in binary: lastlog And I see more... Just look for yourself. :-)

...

...

The user "space" is not really well defined or understood in Linux. There is no middle ground. Something that is readily availabe in Java does not even exist in Linux.

Well, no. Linux, or rather Unix, was designed with a single admin with full powers. It is not that simple to modify this basic idea.

I know, but I'm trying anyway. Cause the current system causes groups to not be used, and causes problems for me. So I need to get around it anyway.

No, you can't. You can use tricks, but there is only one root, and he can not delegate that easily - except with sudo and groups. And acls. You can not define a root.for.mail admin that can do anything on all the mail directories and programs. Instead, you have to modify the permisions for groups on those directories, specify sudo commands for anything he might need, and provision for files that on creation/modification on those directories have appropriate permissions so that he has full control of them. A Windows server admin has a more complex and fine grained set of permissions, including creating partial administrators. Hey, I'm a Linux guy, but the truth is the truth... Not that it is simple in Windows, either. Far from it. Say, a backup admin. In Linux it has to be root.

...

On the other hand, it is quite feasible for the designer of any application to allow it to be administered by another user.

You mean with a setuid program or something of the kind?

Yes, something, if the application is designed from the start to be administered by somebody else. Databases, for instance, typically have a database admin with a different name from root, if specified. He probably can not install the database on the computer, though. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2016-04-11 at 08:06 +0200, Per Jessen wrote:

Carlos E. R. wrote:

...

Say, a backup admin. In Linux it has to be root.

It's not that you can't do it on Linux, it's simply that noone has put any (or enough) effort into developing a framework for managing and delegating permissions and such. You can actually do quite a lot with sudo, but yes, it's cumbersome.

Well, the way I think about it, we would need privileged UIDs. Think of a backup admin: he needs execute permissions on all directories, and read access on all files, and those permissions must be assigned by default to all new files and directories. In effect, he needs read access to all files owned by UID 0. Another, related, feature, is seen by the trick some do of creating another admin user with UID 0 besides root. These are very basic access, they need, I think, a core redesign of how Linux/Unix work. Some kind of delegated/effective UID 0, without being it, not needing to alter the permissions of files. No, I do not know how to do it, or being more precise. :-( Perhaps negative numbers, to flag that they are special. Then a structure listing what each of those UIDs can do. Like a list of directories to which they have superseding permissions. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcLefcACgkQtTMYHG2NR9VnBwCgkgG2x5aBEIITLkSKnGZWPEm2 egoAn0UBX2tyMh4q0kYAbUqGcEAmtvYV =7odT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2016-04-11 at 12:57 +0200, Per Jessen wrote:

Carlos E. R. wrote:

There is software for that sort of thing out there, just not open source (as far as I have seen). Try googling e.g. "unix admin separation privileges".

It's been practised at the enterprise level for decades, AIX, HP-UX and Solaris have probably all had this functionality for quite some time.

Yes, I have used Unix machines with a layer on top of Unix that had that kind of access control. In essence, it was a complicated and very expensive application running on Unix and controlling who did what. There was a command, though, that gave access to the unix terminal, as root... - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcLjIIACgkQtTMYHG2NR9VyoACfWD5mJhP5ANQMNawHP4HEho9y j6kAoJmAdPrU2DdPZvG8VN91af1TklKc =TRAA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen schreef op 11-04-16 12:57:

If somebody needed a backup admin, you're right. What I think somebody might need is a "storage admin" who will for instance manage when, what and how backups are made, but it would not mean he/she would have access to any of those backups. For _running_ the backups, some areas might still require root, but far from all. The backup process for a mysql database would require the user for that instance. The backup process for an apache vhost would require the user for that vhost. etc etc.

Having dedicated "admins" like that would really make the opportunity for creating security holes that gave access to full root, much harder to do. You could even imagine: this was my imagining. Okay don't laugh, or maybe do. What IF. You create a secret government :P. You immunize a certain set of essential files pertaining to security. You disallow root to change them. You create a hidden user that even root cannot see. Since no one but that user (or his cronies) can see the user, and since the files that govern this cannot be changed (except for the user) you have effectively created a super-root that no one knows about (except you). Now actually you also want to limit the rights of the super-root or nothing will have changed (you would just have a new root). But next you do is create a hidden part of the filesystem (again, only visible to the super-root) and you use this as the place where you keep your auditing logs, and perhaps your backups as well. Effectively it would be very much like having a different system that has different user accounts and where logs are sent to (and backups). It's actually not much different from that. Actually it's the exact same thing only on one system. You know, the idea of "someone compromises root on system A, but cannot clear his trails because the auditing has already been sent to system B, that he cannot access". So now you have a special backup daemon/user/process that also has access to this hidden area for storing the backups. I'm not sure how to do it, but the super-admin would by default not have all the same rights that root does have. The super-admin is the only one who can "invisiblize" parts of the system to everyone else. But he doesn't need (write) access to every other part of the system. Much like our real secret governments do. So the super-admin controls the core security files. He/she could therefore change them and open up everything else in the system as well..... hmmm.... But really do you not want this user to have the authority that root has. That's a logical impossibility if the super-admin can change the entire security system.... namely the programs and libraries that control it (and configurations). My system needs some working :p. The whole reason for this system is that if some hacker enters the machine, he might destroy the contents of the machine but never get access to the "safe" vault unless he knows how to get there. But knowing how to get there would be rather difficult because root would not be able to see it or find any traces of it, the backup user does, but root won't see any open file handles, you could even go so far as to hide statistics but then you'd at some point run into anomalies ;-). In fact the only way to get to the super-admin might be through some less-privileged user. But this thing might not be visible (and might still require a secret) while using all of the standard tools (such as su).

There is software for that sort of thing out there, just not open source (as far as I have seen). Try googling e.g. "unix admin separation privileges".

It's been practised at the enterprise level for decades, AIX, HP-UX and Solaris have probably all had this functionality for quite some time.

I think it is a real shame that Linux is so primitive, but then again, that makes it possible to design your own thing on top of it. The problem with "less-primitive" is that someone might design something you do not like, and now you are stuck with it (think systemd). The more primitive something is, the less chance someone will have taken a turtle and built a castle on top of it (just to name something silly). Primitive tools have the tendency to do only one thing and do them well. A hammer is a hammer. A motorized hammer with phase-shift ability might not do what you want ;-). Design flaws also have less impact if the system is small or still at its beginnings. The bigger the system is, the worse a design flaw will become.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen schreef op 11-04-16 08:06:

Carlos E. R. wrote:

...

No, you can't. You can use tricks, but there is only one root, and he can not delegate that easily - except with sudo and groups. And acls.

You can not define a root.for.mail admin that can do anything on all the mail directories and programs. Instead, you have to modify the permisions for groups on those directories, specify sudo commands for anything he might need, and provision for files that on creation/modification on those directories have appropriate permissions so that he has full control of them.

A Windows server admin has a more complex and fine grained set of permissions, including creating partial administrators. Hey, I'm a Linux guy, but the truth is the truth... Not that it is simple in Windows, either. Far from it.

Say, a backup admin. In Linux it has to be root.

It's not that you can't do it on Linux, it's simply that noone has put any (or enough) effort into developing a framework for managing and delegating permissions and such. You can actually do quite a lot with sudo, but yes, it's cumbersome.

Thank you for thinking on this. Personally I think you can get very far with what Carlos here describes, but it is also the only way. "Instead, you have to modify the permisions for groups on those directories, specify sudo commands for anything he might need, and provision for files that on creation/modification on those directories have appropriate permissions so that he has full control of them." Indeed, this is what the group feature provides. I don't really have a need for anything else at this point. It is just annoying to know how any specific application must be told to give g+w permissions to everything. And to discover if that will introduce any risks. I don't think there is yet a filesystem provision that you can say: this directory tree? Everything g+w, no matter what anyone says. In effect if you were in the position to code it, the most effective thing would be a daemon that just monitors a tree you have told it to monitor, and just fix any permissions as required. I wouldn't mind making something like that. (But I have no skill in C and system development yet). These 3 things: - group-based permissions for a certain tree - automatic "group" ownership for all included files (g+s) and automatic group permissions for all included files (g+w) - a daemon that monitors permissions and corrects them if wrong Is really something I would like to achieve.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 2016-04-11 at 16:42 -0400, Greg Freemyer wrote:

Lots of conversation of giving people selective admin roles and no mention of ACLs?

ACLs can be used to override the basic Linux permissions and maybe the above desire of Xen?

So if a single user needs to have expanded permissions you can use ACLs to give them to them.

Also, ACLs have default inherit features, so you can set a directory to cause new folders / files created within it to inherit the ACLs.

So if you want to give a user rw permission to the /etc/postfix folder, just add an override ACL for him to the folder.

I wrote an article on the old opensuse wiki (old-en.opensuse.org) on using ACLs to allow a sales team (group) and a finance team (group) to share a folder and have newly created files in the folder inherit the default ACL setup.

Unfortunately, I don't know how to find that old wiki page and I don't think it was migrated to the new wiki (en.opensuse.org). I don't have that many edits on the old wiki, so if someone knows how to get a list of them, it shouldn't be hard to find that page again.

? https://old-en.opensuse.org/How_to_share_directories_between_groups_of_users... ? Cheers, Dave PS go to https://old-en.opensuse.org/Welcome_to_openSUSE.org and search for acl

Greg

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Apr 11, 2016 at 6:11 PM, Xen wrote:

Dave Howorth schreef op 11-04-16 23:06:

...

https://old-en.opensuse.org/How_to_share_directories_between_groups_of_users...

That is pretty awesome. Unusable without a GUI though.

I didn't even know that thing existed man!! I have never seen anyone use it (online).

I am a slight bit embarrassed.

This actually solves my current problem completely

It is a hassle to work with, but very flexible at the end of the day. That's why I was surprised the thread was pretty deep and no one had brought it up yet. fyi: Windows has ACLs for NTFS as well. I find them a nightmare to work with in Windows. I think they are much cleaner in Linux. Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Xen writes:

It's just that without a GUI you won't have any real awareness of it and now you need to 'constantly' use that getfacl to keep an awareness of the condition of your system.

I get interested, so I did some research. There seem to be Eiciel[1], which is part of OpenSUSE Charles Footnotes: [1] http://www.linux-mag.com/id/2735/ -- "It's God. No, not Richard Stallman, or Linus Torvalds, but God." (By Matt Welsh)

Greg Freemyer schreef op 12-04-16 00:30:

fyi: Windows has ACLs for NTFS as well. I find them a nightmare to work with in Windows. I think they are much cleaner in Linux.

Yeah, it's horrid isn't it. Windows these days locks everything down in C:\Program Files. And some other dirs are even worse. Gaining access to something might mean half an hour of messing around because you have to do everything in the right order, oh and then at the end of the day you discover that a certain kind of override doesn't work, or you cannot give permissions to the user if the group denies it, or vice versa, or ..... I may have one question though, maybe you can answer it. ** What happens if you make a tar backup of ACL-ed files? ** Easy to test. It does, if you specify --acls when both saving and extracting the files. (I think). Another flag to remember. However, whenever I am not superuser, it will not preserve any ownership (which is in a sense logical) (but at the same time it will preserve all ACL rights). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. schreef op 12-04-16 14:00:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Tuesday, 2016-04-12 at 02:27 +0200, Xen wrote:

...

Another flag to remember. However, whenever I am not superuser, it will not preserve any ownership (which is in a sense logical) (but at the same time it will preserve all ACL rights).

So, can we have a backup admin using ACLs?

Yes you can have anything. There are no limits to the system. However it probably does require permissions (ACLs) to be propagated down a tree on every file creation, and this is the administrative burden. You need to ensure that these ACLs are set, and if some user takes it away, you lose permissions. I think. There is not some kind of master permission on the root of some tree, that is going to apply to all files indiscriminately, I think. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, Apr 12, 2016 at 9:02 AM, Carlos E. R. wrote:

On 2016-04-12 14:45, Xen wrote:

...

Carlos E. R. schreef op 12-04-16 14:00:

...

...

So, can we have a backup admin using ACLs?

Yes you can have anything. There are no limits to the system.

I'll expand. Will user and group permissions be kept on the backup copy made by a plain user? Or will they be changed to be owned by the user doing the backup?

I believe they are changed, so the answer to my question is "not quite".

Untested, but logically the backup should maintain the correct data assuming the backup tool understands ACLs. 15 years ago when I was experimenting with ACLs, "star" was a modified version of tar that groked ACLs in the backup set. The issue is the restore. I suspect only root can do a restore and get everything set correctly. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, Apr 12, 2016 at 2:26 PM, Carlos E. R. wrote:

On 2016-04-12 18:58, Greg Freemyer wrote:

...

On Tue, Apr 12, 2016 at 9:02 AM, Carlos E. R. <> wrote:

...

...

I'll expand. Will user and group permissions be kept on the backup copy made by a plain user? Or will they be changed to be owned by the user doing the backup?

I believe they are changed, so the answer to my question is "not quite".

Untested, but logically the backup should maintain the correct data assuming the backup tool understands ACLs.

If the backup is somekind of archive, it should work. But if the backup is something like rsync, which creates identical files on the destination, I have my doubts.

note rsync has a "--acls" arg which is supposed to copy the ACLs to the desitination. But I doubt it would work perfectly if not run as root.

...

15 years ago when I was experimenting with ACLs, "star" was a modified version of tar that groked ACLs in the backup set.

The issue is the restore. I suspect only root can do a restore and get everything set correctly.

Yes, I think so.

which is why I suspect rsync will fail. It is effectively doing a "restore" of the folder structure at the destination. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 2016-04-12 at 14:33 -0400, Greg Freemyer wrote:

On Tue, Apr 12, 2016 at 2:26 PM, Carlos E. R. wrote:

...

On 2016-04-12 18:58, Greg Freemyer wrote:

...

On Tue, Apr 12, 2016 at 9:02 AM, Carlos E. R. <> wrote:

...

...

I'll expand. Will user and group permissions be kept on the backup copy made by a plain user? Or will they be changed to be owned by the user doing the backup?

I believe they are changed, so the answer to my question is "not quite".

Untested, but logically the backup should maintain the correct data assuming the backup tool understands ACLs.

If the backup is somekind of archive, it should work. But if the backup is something like rsync, which creates identical files on the destination, I have my doubts.

note rsync has a "--acls" arg which is supposed to copy the ACLs to the desitination.

But I doubt it would work perfectly if not run as root.

Run rsync as a daemon "The daemon must run with root privileges if you wish to use chroot, to bind to a port numbered under 1024 (as is the default 873), or to set file ownership. Otherwise, it must just have permission to read and write the appropriate data, log, and lock files." It's pretty secure I think. But in any case, the permissions on the backup server are a separate concern to those on the source machine. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, Apr 12, 2016 at 8:45 AM, Xen wrote:

Carlos E. R. schreef op 12-04-16 14:00:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Tuesday, 2016-04-12 at 02:27 +0200, Xen wrote:

...

Another flag to remember. However, whenever I am not superuser, it will not preserve any ownership (which is in a sense logical) (but at the same time it will preserve all ACL rights).

So, can we have a backup admin using ACLs?

Yes you can have anything. There are no limits to the system.

However it probably does require permissions (ACLs) to be propagated down a tree on every file creation, and this is the administrative burden.

You need to ensure that these ACLs are set, and if some user takes it away, you lose permissions. I think.

There is not some kind of master permission on the root of some tree, that is going to apply to all files indiscriminately, I think.

I'm not truly expert with ACLs, but I think you can set a default ACL in every currently existing folder to be inherited by any newly created files and folders that are direct children of the folder. So if you create a "backup" user and give it read access to every existing folder and file and also make that ACL be applied to newly created files and folders by default, all should be good. If someone wants to block access to the "backup" user, then that can be done but it takes an active step on the part of the file owner (or root). The bigger issue might be restores. It may require root access to properly restore a random file tree. This whole backup (and restore) user concept implemented via ACLs would make a good post for a blog (lizards?). fyi: With windows the Backup role can actually have more access than the Administrator role. I've tried to access the equivalent of /dev/sda on a windows box before and have it fail for the Administrator. We had to add the backup role to the Administrator account before it would work. As far as I know that level of granular access is beyond what Linux ACLs can provide. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer schreef op 12-04-16 00:16:

Perfect. Thanks,

I didn't realize that page is from 2007 (9 years old!).

It doesn't do exactly what I recalled, but it is still a decent intro to how ACLs can be used to give the "management" team access to 2 other groups files without giving management full root access.

What more did you expect it to do / list? It cannot just give "management" access to two directories belonging to other groups, it can also give group "IAM YOUR ENEMY" access to everything else on the system you don't want it to have access to :P. And even a single user as well. Pretty awesome. Just override everything. Add a ACL and override everything. Who cares about regular permissions right. :). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2016-04-08 at 17:35 +0200, Xen wrote:

I must say personally I feel "logger" is quite convenient, but you don't get to specify any alternative log file.

You can use one of the seven local or user facilities, and then configure the syslog daemon to send that to a different file. Or, use logger with a defined "--tag", and filter on it.

Personally I would prefer a more custom made or personal thing that logs only stuff that I want personally to be logged.

Yes, but syslog takes care of timestamp and caching the writes. And rotating the files is easy. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcI3V4ACgkQtTMYHG2NR9V7pgCeJnr8b7308jWqm5wcaU/m6Zoh TsgAn3W7kWsDH0SRDbckGR5Y8/G/EZaE =TzoE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

You do know squid outputs to its own logfile right? Normally it would output to /var/log/squid.

Yes.

You get to specify those directories when you compile.

I think they are ./configure options.

Yes. It is a improper example here. but, some package, e.g. shadowsocks (one socks5 proxy), it just output log to stdout, when run in background, i need add log myself. -- Geek, Rubyist, Emacser 程序员中的牛逼运维， 运维中的牛逼程序员。 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2016-04-09 at 16:24 +0200, Xen wrote:

I think:

- edit /etc/logrotate.conf OR create custom logrotate.conf - in latter case add custom user crontab for it - add a line and file to a custom /etc/rsyslog.d/ file, in other words based on /etc/rsyslog.d/50-default.conf (on my system), add a facility.priority pair (such as user.info)

This is the list of facilities:

auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp and local0 through local7

This is the list of priorities:

debug, info, notice, warning, err, crit, alert, emerg

- now feed the output of your program to "logger -p facility.priority".

- or possibly "logger -p facility.priority -t tag"

Now the regular syslog daemon (rsyslog) should output the log of that specific program to that specific file associated with that specific facility.priority pair.

This what you guys mean right.

Thank you Carlos?

Yes, that's a nice summary :-) - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlcJOVAACgkQtTMYHG2NR9UuXgCfX2Ypu65lxQ7tN0o8GMD+16Rc 8pQAn2cdDHWiky1acHpRpjnG7KoX/nff =R8Hv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Billy.Zheng(zw963) wrote:

basically, the reason is, e.g. squid, though some like improper. because squid have own log builtin support when compile.

1. I want to use the last version squid in my VPS. so, i have to compile it myself.

2. I need a common startup script for squid to start. simply enough, I add one line in my crontab '@reboot /usr/local/bin/start_squid' `start_squid' is a bash script for start squid correctly.

3. i want to record log to file, for some net analysis. I am not a linux administrator, less experience for logger, i hope spend minimum cost to achieve a sysetm logger like service. function included following: - rotately automatically. - can be output real time if need.

Is the openSUSE supplied squid really too old for your purposes? It seems it would be a lot less work to use that.

I often read log when in programming development, so i think log is useful in this case.

The problem is:

1. What is the correct way to add my startup script log into journalctl or something else?

You create a systemd service unit, maybe "mysquid.service". See man systemd.service for details and look at some existing ones for inspiration. Or install squid from the openSUSE repo, and just update the service unit to fit your squid binary.

2. if use `ssh -vvv 2>~/ssh.log' way, should i must to add rotately function myself ? is there exist convenient way for this?

AFAIK, as long as ssh is running, ~/ssh.log will be kept open. If you rotate that file, ssh will need to be restarted.

...

-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?

As Anton hinted above, please don't top-post, it's a bad habit. -- Per Jessen, Zürich (6.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/02/2016 10:27 PM, Billy.Zheng (zw963) wrote:

My VPS use openSUSE 42.1, I deploy some application in it, with some self-defined boot start bash scripts, I want a simple way to write all application log to same file.

start_some_application |logger

I hope it logger output to one file which I familiar and commonly. the only I know from slackware is /var/log/messages.

so, I don't know if some *service* is depend on /var/log/message.

In Date: Wed, 02 Mar 2016 02:26:52 +0800 Message-ID: <87h9gq6olv.fsf@163.com> You said

And, some service is not start correctly cause this file missing?

So long as the application/service/daemon/whatever uses the syslog protocols there should not be a problem. Why would a program want to write directly to /var/log/<anything>? After all. you make calls to the system to write rather than writing directly to the disk and trying to replicate the file system drivers inside applications. I think your problem here has to do with this: Why are you logging activity? Most desktop users have little use for the logs under normal conditions, they are there for when things go wrong or as a record of "when did I do that?". When things go wrong its different and logging is turned right up and the logs are viewed in real-time. Think, for example, of "ssh -vvvvv". The real-time viewing of that can be done with filtering ("artificial ignorance" of other items) using journalctl. Its different for a large installation,a bank, brokerage, ISP, where either activity needs to be recorded and retailed (... for six months ... for 7 years ...) or where the real time activity of illegal intrusion or ex-filtration needs to be spotted and responded to. But once again, the high level tools, possibly even ones that come from 3rd parties, are there and there is no need for low level file activity. I can imagine other types of logging. I keep a hand written book that regular readers will record me mentioning, in which I record my 'experiment's and trials' and the reasons for the decisions I made and my thoughts about the results. My recent posing about creating an encrypted LVM LV is an example of that. Why hand written and not on-line? It needs to be accessible when I'm off-line, for example when carrying out an installation. So, what is the purpose of the logging that you are wrestling with here? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

...

echo 'some special log output' | xargs logger

My release is openSUSE 42.1, where is my logger to find? There is not exist a file named /var/log/messages (Like Slackware linux I used.) Per Jessen writes:

Billy.Zheng(zw963) wrote:

...

From logger command man:

...

...

logger - a shell command interface to the syslog(3) system log module

So, I want to use this command to write log to syslog.

following is a test:

$: echo 'some special log output' |logger

but, i could not found anything about my log in /var/log/.

...

From the man page:

logger [options] [message]

For your test to work:

$: echo 'some special log output' | xargs logger

-- Per Jessen, Zürich (6.0°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.

-- Geek, Rubyist, Emacser Homepage: http://zw963.github.io -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2016-03-01 19:25, Billy.Zheng (zw963) wrote:

...

There is not exist a file named /var/log/messages (Like Slackware linux I used.)

Of course it doesn't. openSUSE uses systemd, meaning that there is no syslog by default.

Actually, that was by choice because someone decided there was no need for a syslog daemon. -- Per Jessen, Zürich (3.7°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh wrote:

Per Jessen wrote:

...

Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2016-03-01 19:25, Billy.Zheng (zw963) wrote:

...

There is not exist a file named /var/log/messages (Like Slackware linux I used.) Of course it doesn't. openSUSE uses systemd, meaning that there is no syslog by default.

Actually, that was by choice because someone decided there was no need for a syslog daemon.

---

Wasn't that a side effect of someone deciding the default would be for SDto log as little as possible, and what it does log, it was to keep in transient storage so the log would be cleared each boot?

To be honest, I'm not sure. I seem to recall something about a syslog daemon being superfluous because the journal does it all. Maybe also something about the main target user of openSUSE not needing a syslog? It matters not, just one more thing for the checklist when installing :-) -- Per Jessen, Zürich (4.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-03-02 09:17, Per Jessen wrote:

It matters not, just one more thing for the checklist when installing :-)

Besides that, it means more work on the cpu and disk, because it writes a log that I do not use (the journal) and syslog, than I do use. The journal can take gigabytes after two weeks with the computer running. Telcontar:~ # journalctl --disk-usage Journals take up 272.0M on disk. Telcontar:~ # Telcontar:~ # uptime 10:02am up 5 days 1:07, 40 users, load average: 0.30, 0.30, 0.27 Telcontar:~ # It is bigger than /var/log, which covers years of data: Telcontar:~ # du -hcsS /var/log 264M /var/log <=== 1.1G total Telcontar:~ # Despite having: /etc/systemd/journald.conf: SystemMaxUse=100M RuntimeMaxFileSize=200M A lot of that is mail and nntp logs. I would like to selectively purge the journal, but no idea how to, even if possible. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Anton Aylward wrote:

In a corporate setting logging of activity is important. But writing to a file is slow. Some of the higher end activity analysers used by, for example, banks, to detect suspicious (read: 'nefarious') activity end up writing to a database. perhaps that's faster.

Almost certainly not. It's the same data that needs to end up on disk, adding a database to the mix will slow it down, but make analysis and structured access easier.

The whole idea of the journald is that it is faster to have the events logged a binary and only translated to human readable when needed.

Anton, it's a bit early for april fools. Most stuff logged to syslog comes in text format anyway. I am not sure what the whole idea of systemd was or is or was meant to be, but it was certainly about not speed for corporate settings. -- Per Jessen, Zürich (3.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-03-02 18:37, Per Jessen wrote:

Anton Aylward wrote:

...

In a corporate setting logging of activity is important. But writing to a file is slow. Some of the higher end activity analysers used by, for example, banks, to detect suspicious (read: 'nefarious') activity end up writing to a database. perhaps that's faster.

Almost certainly not. It's the same data that needs to end up on disk, adding a database to the mix will slow it down, but make analysis and structured access easier.

That's it. It is machine reading without needing to parse the results what is faster, because it is already "parsed", so to speak. In fact, reading (dumping) the systemd journal is terribly slow because (educated guess) heavy on disk fragmentation. Unless the HD is an SSD.

...

The whole idea of the journald is that it is faster to have the events logged a binary and only translated to human readable when needed.

Anton, it's a bit early for april fools. Most stuff logged to syslog comes in text format anyway. I am not sure what the whole idea of systemd was or is or was meant to be, but it was certainly about not speed for corporate settings.

It would be faster writing if you write in the exact same format as the log entries exist internally before being written. There is a timestamp, binary, a facility/priority field, a number, pid, a number, and the rest is text (the log entries plus names) at variable size. All that is adapted for storage in a database, and the text compressed. Can't be faster. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-03-03 08:29, Per Jessen wrote:

Carlos E. R. wrote:

...

In fact, reading (dumping) the systemd journal is terribly slow because (educated guess) heavy on disk fragmentation. Unless the HD is an SSD.

Yes, I remember reading something about at some point. I don't use the journal myself, I always run syslog-ng.

Me too. Well, rsyslog. But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp. Telcontar:~ # time journalctl --no-pager | grep "fetchnews\|postfix\|fetchmail" | wc -l 202170 real 0m7.878s user 0m6.173s sys 0m1.351s Telcontar:~ # That in six days. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-03-03 11:14, Per Jessen wrote:

Carlos E. R. wrote:

...

But I'd prefer not to have journal running. Or at least impede some entries from going into it, like email or nntp.

Doesn't "rm -Rf /var/log/journal" mostly take of it?

Well, I suppose so, but it seems a crude way of doing it. It would be more reasonable to remove entries based on criteria. Even better, impede them being logged. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-03-03 11:41, Per Jessen wrote:

Carlos E. R. wrote:

...

...

Doesn't "rm -Rf /var/log/journal" mostly take of it?

Well, I suppose so, but it seems a crude way of doing it.

ISTR it being the recommended approach.

How crude...

...

It would be more reasonable to remove entries based on criteria. Even better, impede them being logged.

Then look at your postfix and nntp configs, that's where the logging should really be restricted.

No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-03-03 11:55, Per Jessen wrote:

Carlos E. R. wrote:

...

No, no. I want the log in syslog, where I know where to filter appropriately and rotate when needed. What I do not want them is in systemd journal wasting space and resources.

Ah okay - well, the systemd journal is the gateway to the syslog daemon. I think we're back to removing /var/log/journal - there may be something in /etc/systemd/journal.conf too, but I remove /var/log/journal. Just another item on the checklist.

Wait. I don't have "/var/log/journal/", that's the permanent journal. There is another journal for the current session only, which in theory goes to memory, but mine is big: Telcontar:~ # journalctl --disk-usage Journals take up 304.9M on disk. Telcontar:~ # uptime 12:01pm up 6 days 3:06, 42 users, load average: 0.27, 0.45, 0.38 Telcontar:~ Despite having in /etc/systemd/journald.conf: SystemMaxUse=100M RuntimeMaxFileSize=200M I'm unsure where this one is stored. On each boot, it is purged. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Le 03/03/2016 14:13, Per Jessen a écrit :

I wonder if we do actually create /var/log/journal in the default setup. I mean, a desktop machine doesn't need a persistent log.

? needed to debug boot problems jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 03/03/2016 15:41, Per Jessen a écrit :

jdd wrote:

...

needed to debug boot problems

I was just quoting Andreas Jaeger. We stopped installing a syslog daemon because our main audience doesn't need one.

I read the thread, but fail to understand. journalctl still makes a better job than the previous /var/log/message IMHO journalctl -b 0 is very fast: time journalctl -b 0 > null real 0m0.097s user 0m0.072s sys 0m0.024s and as I need to read it and usually read it, some second delay do not change anything jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-03-03 16:16, Per Jessen wrote:

It all depends on what you do with /var/log/(messages|mail|firewall). The systemd journal certainly does not replace syslog-ng, for instance. (except maybe on a single-user desktop machine at home).

Most of my logs are rotated daily, archived and analyzed (for anomalies, statistics and other feedback). I have a couple of cases where daemons are fed loglines directly from syslog-ng (see the program() option). Maybe that's all possible with journalctl, but syslog-ng does an excellent job.

Indeed it does. For instance, those verbose logs that are not needed after a week I rotate and discard fast. Others I keep for years. I can play with that. On the systemd journal either I delete it all or nothing. I can not remove the nntp entries, for instance, which are huge. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-03-03 19:44, Anton Aylward wrote:

On 03/03/2016 10:43 AM, Carlos E. R. wrote:

...

On the systemd journal either I delete it all or nothing. I can not remove the nntp entries, for instance, which are huge.

Once again this is a configuration issue. I no longer run a nntp service, but when I did I had it set up under a distinct UID. Journald does have the ability to separate out logs for a specific UID.

Or, as I've shown previously, for a specific COMMand.

And then, delete them? What I want is delete some specific entries, by facility and level, and keep others for years and years. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

jdd wrote:

Le 03/03/2016 19:58, Carlos E. R. a écrit :

...

What I want is delete some specific entries, by facility and level, and keep others for years and years.

or simply fork these entries to an other account and let the system roll the logs as usual

the usual logrotate did not remove anything and accumulated years of tgz

"what I want" is obviously wrong.

It's clear from what you said that what you want is keep track of some part of the logs. The way you can do it with journalctl may not be the same than previously, that don't mean it can't be done. and if it can't, open a bug report

s/bug report/feature request/ And then don't hold your breath. jdd, of course journald/journalctl does not do all of what syslog-ng/rsyslog does. It's backward and cumbersome to begin with, (which can be overcome with appropriate command aliasing), but it is not a syslog daemon, period. -- Per Jessen, Zürich (2.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2016-03-03 20:07, jdd wrote:

...

Le 03/03/2016 19:58, Carlos E. R. a écrit :

...

What I want is delete some specific entries, by facility and level, and keep others for years and years.

or simply fork these entries to an other account and let the system roll the logs as usual

the usual logrotate did not remove anything and accumulated years of tgz

No, not true. Logrotate compresses the current log, and limits the compressed logs either by date or by number of files, removing the rest.

Uh, for e.g. /var/log/messages, the default config in logrotate does indeed not remove very much: compress dateext maxage 365 rotate 99 missingok notifempty size +4096k Probably a fairly sound default setting. -- Per Jessen, Zürich (2.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2016-03-04 08:54, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

No, not true. Logrotate compresses the current log, and limits the compressed logs either by date or by number of files, removing the rest.

Uh, for e.g. /var/log/messages, the default config in logrotate does indeed not remove very much:

compress dateext maxage 365 rotate 99 missingok notifempty size +4096k

Probably a fairly sound default setting.

They are removed after a year, if I read it correctly.

rotate 99

means a maximum of 99 rotated files.

I'm not sure, according to the man page "rotate count: Log files are rotated <count> times before being removed". I think it means nothing is deleted until you have 99 rotated files.

For instance, I have this:

/var/log/news/news.debug { compress dateext maxage 30 rotate 10 ...

which rotates quickly the news.debug file.

Well, what's the limit - size or time? (daily/weekly or size +xxx) ? -- Per Jessen, Zürich (5.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 04/03/2016 15:36, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

rotate 99

means a maximum of 99 rotated files.

I'm not sure, according to the man page "rotate count: Log files are rotated <count> times before being removed". I think it means nothing is deleted until you have 99 rotated files.

Well, yes, it is the same, ¿no?

I dunno. If one new rotated file of 4Mb is created once a week, you only get 52 in year1. In year2 you get another 52, so 104 - I don't know if 99 are kept or only those younger than 365 days.

...

...

For instance, I have this:

/var/log/news/news.debug { compress dateext maxage 30 rotate 10 ...

which rotates quickly the news.debug file.

Well, what's the limit - size or time? (daily/weekly or size +xxx) ?

30 days and 10 files. Size applies to the active file.

Size is the criteria for rotation - unless your news.debug file satisfies your criteria, nothing is rotated. If you have "size +100G" for instance. On production machines, I always use: daily rotate 30 To me rotate and maxage do the same thing, limit the number of rotated logs, just with different criteria. I can't quite work out how they work together. How do you believe your "maxage 30 and rotate 10" is supposed to work? -- Per Jessen, Zürich (4.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

It simply can't be done reliably. If you need to keep an archive of logs, it has to be plain text, perhaps compressed, so that they can be kept anywhere and retrieved anywhere, without special tools. Say, keep logs in CDs, for instance.

Le 03/03/2016 22:29, Carlos E. R. a écrit : true, but are you sure it can't be done? jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2016-03-07 19:54, jdd wrote:

...

Le 03/03/2016 22:29, Carlos E. R. a écrit :

...

It simply can't be done reliably. If you need to keep an archive of logs, it has to be plain text, perhaps compressed, so that they can be kept anywhere and retrieved anywhere, without special tools. Say, keep logs in CDs, for instance. true, but are you sure it can't be done?

Quite!

You can not archive for long term a binary database on a different media. You need to also archive with it the software needed to read it.

Tape is your answer. The only media guaranteed and tested for 20-30 years storage. -- Per Jessen, Zürich (1.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2016-03-08 10:04, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

You can not archive for long term a binary database on a different media. You need to also archive with it the software needed to read it.

Tape is your answer. The only media guaranteed and tested for 20-30 years storage.

Paper is for millennia :-p

Heh, check your grandfathers old papers - brown, bleached, ink disappeared or soaked into the next page. Maybe laser-printed will last for long enough, dunno.

Realistically though, shuffling to another hard disk is enough for me.

I think I read about a memory crystal somewhere. Perhaps an article in the OT list.

Yes, there is stuff like that coming out, there is also "long-life" CDs and DVDs, although the latter have not been sufficiently tested either. -- Per Jessen, Zürich (1.3°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 08/03/2016 10:04, Per Jessen a écrit :

Tape is your answer. The only media guaranteed and tested for 20-30 years storage. I you can keep the hardware. my HP tape recorder eated my tapes :-(

jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 2016-03-08 at 19:40 +0100, jdd wrote:

Le 08/03/2016 10:04, Per Jessen a écrit :

...

Tape is your answer. The only media guaranteed and tested for 20-30 years storage. I you can keep the hardware. my HP tape recorder eated my tapes :-(

Media might be guaranteed for 20-30 years. But not the content. If anything goes wrong, you get your money back for the tapes. But not your data. Have quite a reasonable amount of DDS2-tapes, and some time ago decided to use those again (some were used, other brand new) Writing to them isn't such a problem, only thing you need is patience. Ofcource, I wrote them back to an empty dir, and checked the hashes: all fine. Alas, one year later most of them could not be read back anymore. Not even on the tape-unit I used for writing.. Ergo, never put your trust on a single instance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/03/2016 08:41 AM, jdd wrote:

Le 03/03/2016 14:13, Per Jessen a écrit :

...

I wonder if we do actually create /var/log/journal in the default setup. I mean, a desktop machine doesn't need a persistent log.

?

needed to debug boot problems

Indeed. And once things are running stably ... ? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

jdd wrote:

I manage a handful of servers and nearly never have use of logs, but once in a while I'm very glad to have them.

Which is exactly why we have them - for that once in a while. There are other uses and purposes, but that is no doubt the main one for most people. Diskspace has been increasingly plentyful since the mid-90s, so keeping 30days worth of logfiles is not a luxury.

I think the problem is elsewhere. Linux/unix is a very ancient system, now, and old systems are very stable and everybody knows how to use them. Building houses with logs (wood ones :-), is the same, but what for skyscrapers?

on modern computers, million times more complex and powerful than what we had, it's normal to have new tools.

The best tools usually survive the rest - no one has yet discovered a better bicycle or screwdriver or pair of scissors or pliers, spoon, fork, knife, needle, zipper, rope, knot, man pages, vi, syslog - etc etc. Actually, somebody did create a "better" man page, but man pages seem to as popular as ever. -- Per Jessen, Zürich (3.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org