It would be nice if we had a Quassel Core instance hosted on Gentoo infra available for Gentoo Devs to use. This would be similar to the irssi+screen already available on pecker, excepting that there's a nicer GUI interface :)
Assuming that we know nothing about Quassel... 1) Multiple users can connect to one core? 2) What is required to be ran by the super-user? 3) What impact is there regarding "man hours" for "continued maintenance" of the service?
1) Yes, although I haven't actually tried myself, the docs clearly state that there is proper multiuser support. 2) The core can run as an unprivileged user (the ebuild defaults to a dedicated "quassel" user), but if using the provided init script, you will need to start it as root (start-stop-daemon does the setuid(quassel)). 3) Assuming the defaults set by the ebuild are used, any user with write permissions to /var/lib/quassel (by default mode 0700, owner quassel:quassel) can add users or change a user's password, using the provided tools. For security reasons, this should probably be only done by someone with root access to the system, as the same file that contains the usernames/passwords also contains the entire chat logs of every user.
(In reply to comment #1) > Assuming that we know nothing about Quassel... > 1) Multiple users can connect to one core? Yes, I know they can but I never did it. It isn't supported through the GUI yet though, I will investigate more and have some feedback soon. > 2) What is required to be ran by the super-user? Nothing, we can have a quassel user that can handle it. FWIW quassel has ssl support > 3) What impact is there regarding "man hours" for "continued maintenance" of > the service? Hardly none. I use it for more than two years. If we ack this, I can take care of its maintainance.
As someone who is running a quasselcore on a personal vserver: > 1) Multiple users can connect to one core? Yes. However, user administration is a bit rudimentary at the moment. (Means fiddling with config files.) I'm sure Sput would be interested in whatever tools we develop though. > 2) What is required to be ran by the super-user? AFAIK nothing (except e.g. adding an unprivileged user for the quasselcore). Is usually started by an initscript, but can be done otherwise. The more interesting question is which database backend to use (sqlite or postgresql), I guess. > 3) What impact is there regarding "man hours" for "continued maintenance" of > the service? IMHO near zero, but we'd need some tools for user management. Adding the quassel author as cc... :)
A few thoughts based on the comments (thx btw). a) We should either log nothing or ask the trustees how long to keep logs. I'd prefer none. b) By my third question, I hinted that infra doesn't want to have to keep "restarting something" or "do this" or that all the time.
(In reply to comment #5) > A few thoughts based on the comments (thx btw). > > a) We should either log nothing or ask the trustees how long to keep logs. I'd > prefer none. That's not possible -- you cannot turn off logging, and old logs do not expire (unless I'm mistaken). However, the logs for a particular user on a particular channel can be deleted by the user at any time, which should completely remove them from the core. The backlog effectively is what the client actually sees, so no log implies that you won't be able to read what anyone says, ever. > b) By my third question, I hinted that infra doesn't want to have to keep > "restarting something" or "do this" or that all the time.
Additional users can be added "easily" by running quasselcore --aduser. We don't have a GUI interface for that though. --adduser does nothing more than add an entry in a database table, so that could be done externally too. Quassel at this time does not support expiring logs, though, since they're stored in a database, users have come up with clever queries to do that externally. Some people are running a cron job that regularly expires logs that are older than a given timeframe... A GUI-based interface for that is planned, but not there yet :) Not logging is not supported, as being able to access the backlog is the main feature of Quassel. For a multi-user setup, I heartily recommend using the postgres backend, as sqlite has serious performance problems in that context (it requires database-wide locking). sqlite is fine for single users though. More questions can be answered in #quassel, and since a metric ton of Gentoo devs are already present in there, I think there should not be any problems :)
I've used it for a while in my server (multiuser installation, with an unofficial mysql backend) it is very stable. Waiting for the green light to prepare cfengine patches and write down instructions.
I'd be interested in this too. I've been one of Theo's testers. :-)
The majority of the infrastructure team voted "no". So we're not going to setup or maintain Quassel on Gentoo hardware. Sorry guys.
(In reply to comment #10) > The majority of the infrastructure team voted "no". So we're not going to > setup or maintain Quassel on Gentoo hardware. > > Sorry guys. That is really unfortunate. What were the reasons to vote against this?
(In reply to comment #11) > (In reply to comment #10) > > The majority of the infrastructure team voted "no". So we're not going to > > setup or maintain Quassel on Gentoo hardware. > > > > Sorry guys. > > That is really unfortunate. What were the reasons to vote against this? Us running it means: 1) We have to do user administration; possibly via syncing from ldap. 2) We have to do daemon administration; start / stop / reload. 3) We are custodians of chat logs of users. We are the de facto custodians of logs of users who use a client on our infra and log into their homedir; so this is probably not too different. There is no reason why this service must be shared (multi-user quassel.) 1) Each user running his / her own core provides user isolation. This includes both performance / uptime as well as data isolation. 2) No user adminstration by infra, as each user runs their own core. 3) Each user can administer their own core (start / stop / configure.) Basically I saw no compelling reason to run a multi-user setup. Users can run their own thing. If we run out of resources on dev.gentoo.org, let me know ;)
(In reply to comment #12) > Basically I saw no compelling reason to run a multi-user setup. Users can > run their own thing. If we run out of resources on dev.gentoo.org, let me > know ;) OK. In that case, can we get quassel emerged on dev.g.o?
Since we now have quasselcore available on woodpecker, we need you to assign us ports we can use, and open them in the firewall. I suggest something in the 50k+ range.
I don't know who installed it, but thank you! Let's file separate bugs for the ports in order to keep records of the requests
Looks like quassel isn't installed on woodpecker right now, so un-fixing the bug.
See #10.
Puppet will now deploy this to woodpecker again. This is against my better judgement, as we've managed to avoid having any Qt on infra boxes up until now.
2024/02/10: Infra is removing Quassel again due to lack of users and cleaning up Qt dependencies.
