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