Any thoughts on how to handle the "logging as non-root" issue?

The problem here that I still don't have a solution for is about the ownership of the /var/log/taskotron directory. What user should own it?

There are multiple situations that we'll need to handle:

• production where tasks are executed by the buildslave user (convention, not required)
• local where tasks are executed by a user (no way of knowing which ahead of time)

The two solutions I can think of are:

1. have 777 permissions on /var/log/taskotron
2. rework logging to run as some sort of daemon user

I don't like either option but I really don't like the daemon option. Can anyone think of another solution to this?

Local execution will in majority cases occur in development environment, for which I've proposed in D129 to completely disable logging. So I don't think we need to care about that use case too much. In the worst case, Petr implemented a fallback logging in D129 - if the main log file is not writable, it will create one in a temporary directory and announce it on stderr.

As for production system logging, I somewhat assume we will be running under root in the future, once the disposable clients are implemented - because some checks will need root to work correctly. For the moment... we can hardcode a specific account name and require production administrators to create it and use it. But I think it's fully satisfactory now to simply use 777. As long as we don't parse logs and do something with them (like in taskotron-trigger in D107), it should be safe (with the only obvious issue that the logs can be altered by someone).

Local execution will in majority cases occur in development environment, for which I've proposed in D129 to completely disable logging. So I don't think we need to care about that use case too much. In the worst case, Petr implemented a fallback logging in D129 - if the main log file is not writable, it will create one in a temporary directory and announce it on stderr.

I'm not sure how you're defining "development environment" here (libtaskotron development or task development) but I'm not sure that matters a whole lot in this case. I suspect that you're right in that file logging isn't terribly important in local execution mode

As for production system logging, I somewhat assume we will be running under root in the future, once the disposable clients are implemented - because some checks will need root to work correctly. For the moment... we can hardcode a specific account name and require production administrators to create it and use it. But I think it's fully satisfactory now to simply use 777. As long as we don't parse logs and do something with them (like in taskotron-trigger in D107), it should be safe (with the only obvious issue that the logs can be altered by someone).

I'm not as worried about the production environment - we have control over that without having to write extensive documentation on setup or worry about whether or not those docs were read/followed.

Are we coming to the conclusion that ownership/creation of /var/lib/taskotron in libtaskotron.spec is not needed or that it should be created with 777. I'm leaning towards the former at the moment but we might want to decrease the severity of the "could not write to log dir" log message if we go that route

In D97#7, @tflink wrote:

I'm not sure how you're defining "development environment" here (libtaskotron development or task development) but I'm not sure that matters a whole lot in this case.

I meant to say "development profile", sorry.

I suspect that you're right in that file logging isn't terribly important in local execution mode

Actually I supposed we would be logging even in development profile, but both @jskladan and @mkrizek persuaded me that it's not necessary when you run the script interactively.

Are we coming to the conclusion that ownership/creation of /var/lib/taskotron in libtaskotron.spec is not needed or that it should be created with 777. I'm leaning towards the former at the moment but we might want to decrease the severity of the "could not write to log dir" log message if we go that route

It didn't even occur to me that we could just skip creating the directory completely. It seems a bit weird to me not to create such a basic directory. Sure, we can require system administrators to do that manually, with permissions they wish. But I wouldn't lower the message severity in that case, it's a big problem when your logs are not stored in a persistent location on a production system. Still, I'd like to avoid too many manual post-installation steps.

What about this? We create /var/log/taskotron with 777. We mention it in our guide. By default, everything works. If some system administrators are not satisfied with the permissions, they can create a custom log directory anywhere else on the disk with their preferred permissions and adjust logdir in the configuration file to point to it. Everyone is happy and manual steps are required only if you need something extra.

There are multiple situations that we'll need to handle:

• production where tasks are executed by the buildslave user (convention, not required)
• local where tasks are executed by a user (no way of knowing which ahead of time)

Why not just create a taskotron group and add the "buildslave" user (for production) and a local user (for testing/devel)? Just curious as I don't know much about permissions and/or sysadmin stuff.

Let's move this forward. I propose to take the simplest approach possible:

What about this? We create /var/log/taskotron with 777. We mention it in our guide. By default, everything works. If some system administrators are not satisfied with the permissions, they can create a custom log directory anywhere else on the disk with their preferred permissions and adjust logdir in the configuration file to point to it. Everyone is happy and manual steps are required only if you need something extra.

From the comments it seems that nobody strongly objects against 777. If we become unhappy about it in the future, we can always change it. I'm no sysadmin either, but Martin's approach in D97#10 seems as a way to go once we need it.

In D97#10, @mkrizek wrote:

There are multiple situations that we'll need to handle:

• production where tasks are executed by the buildslave user (convention, not required)
• local where tasks are executed by a user (no way of knowing which ahead of time)

Why not just create a taskotron group and add the "buildslave" user (for production) and a local user (for testing/devel)? Just curious as I don't know much about permissions and/or sysadmin stuff.

How do you tell which user to add at install time in the testing/devel case? I don't see how this would work in a testing/devel environment.

Why not just create a taskotron group and add the "buildslave" user (for production) and a local user (for testing/devel)? Just curious as I don't know much about permissions and/or sysadmin stuff.

How do you tell which user to add at install time in the testing/devel case? I don't see how this would work in a testing/devel environment.

I think Martin assumed that developers would need to add their user to the correct group manually. It's not completely comfortable, that's true. That's why I like 777 by default and you can use a special dir with special permissions only if you have special requirements.

Why not just create a taskotron group and add the "buildslave" user (for production) and a local user (for testing/devel)? Just curious as I don't know much about permissions and/or sysadmin stuff.

How do you tell which user to add at install time in the testing/devel case? I don't see how this would work in a testing/devel environment.

Manually.

I am fine with the "777" approach btw.