On Tue, Oct 1, 2024 at 12:36 PM Chupin Maxime via Mailman-users < mailman-users@mailman3.org> wrote:

Mark Sapiro wrote:

...

Did you run this as the Mailman user (list in the Debian packages)?

Thank you, I tried, but the system asked me a Password for this user... I do not understand.

sudo -u list mailman-web makemigrations --merge
Password:

The user executing sudo is yourself so enter your own password. It's not the password for user "list" that is wanted. It's your own login password.

-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

Hello,

On Tue, Oct 01, 2024 at 11:08:19AM -0000, Chupin Maxime via Mailman-users wrote:

root@machine: sudo -u list bash

If you are root already, you could also use su:

su - -u list -s /bin/bash -c "mailman-web makemigrations --merge"

(the -s /bin/bash is because the list account has a /usr/sbin/nologin shell in /etc/passwd)

Also note that Debian has a wrapper for mailman commands (but not mailman-web commands), for example:

root@ds-services-mailman:~# mailman-wrapper version GNU Mailman 3.3.8 (Tom Sawyer)

This wrapper, when run from root (sudo mailman-wrapper or just mailman-wrapper under the root user) changes the user to the list user:

root@ds-services-mailman:~# cat $(which mailman-wrapper) #!/bin/sh

su -s /bin/sh -c "mailman $*" list

Not very different from my su above.

On 10/1/24 06:49, Chupin Maxime via Mailman-users wrote:

Thank you, but still asking for Password to execute mailman-web...

Look at the contents of the mailman-web script. My guess is it contains sudo -u list ...

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Thank you. So, using mailman-web makemigrations --merge as root is the right way to do it (as it call user www-data). Unfortunately, I get the error wrote in my first message:

PermissionError: [Errno 13] Permission denied: '/usr/lib/python3/dist-packages/django_q/migrations/0015_merge_0010_auto_20220618_2315_0014_schedule_cluster.py'

That does not change anything... :(

Mark Sapiro wrote:

What user ran the makemigrations --merge?

cat /usr/bin/mailman-web 
#!/bin/sh

su -s /bin/sh -c "python3 /usr/share/mailman3-web/manage.py $*" www-data

What does ls -la /usr/lib/python3/dist-packages/django_q/migrations/ show?

that all the files belong to www-data... but know I get the error for /usr/lib/python3/dist-packages/postorius/migrations. So I change the owner and everything works know.

I’ve done :

root@machine: mailman-web makemigration --merge

and then

root@machine: mailman-web migrate

and now, hyperkitty is working well!!!

Thank you to all of you.

• On 4/16/25 00:06, Sam Darwin via Mailman-users wrote:

su - -u list -s /bin/bash -c "pwd"

That fails on Ubuntu 24.04. Did you mean sudo instead of su? su doesn't have a -u flag. Or which operating system were you on?

Yes, Linux-based su doesn't support the -u option, but sudo does. Probbably an oversight.

The correct call would be:

su - -s /bin/bash -c "mailman-web makemigrations --merge" list

or, if you don't want to run it in a login shell:

su -s /bin/bash -c "mailman-web makemigrations --merge" list

But, all this said, mailman-web is typically already a wrapper calling su -s /bin/bash -c "python3 .../path/to/manage.py $*" www-data, so why should it be wrapped in another wrapper with a different user? The list user is typically used by the mailman-wrapper wrapper.

Mihai

• On 4/16/25 00:41, Sam Darwin via Mailman-users wrote:

Right. The user 'list' goes at the end, instead of -u.

Yep.

...

The list user is typically used by the mailman-wrapper wrapper.

I'm discovering the great usefulness of the mailman-wrapper. :-) So the next question: I used git to check out a bunch of the official gitlab repositories. And then ran this:

grep -r -i "mailman-wrapper" *

no result.

Our server is installed with python and pip packages. Those packages originate from the repos such as https://gitlab.com/mailman/mailman and others. where is mailman-wrapper? Or if that's not provided... well... the grep indicates it's not even mentioned or discussed. And yet such a great cli command! :-) Should that be an open issue or something, for the docs? or, why not?

I've seen mailman-web and mailman-wrappers as scripts in distro packaging (specifically in Debian and Ubuntu), which is generally a discouraged way to install mailman anyway.

In Debian-nomenclature, mailman-wrapper runs a command as the "list" user, while mailman-web runs a command via manage.py as the "www-data" user.

The venv installation doesn't seem to ship those wrappers, which is why people write them themselves or use the whole explicit su mechanism to change to the correct users.

Mihai

• On 4/16/25 01:04, Sam Darwin via Mailman-users wrote:

"Virtualenv Installation, recommended for Production"

It's recommended for production.

I've followed that method. If someone does this, they may never encounter or bump into any files from the "distro packaging (specifically in Debian and Ubuntu)" .

True, and that's fine. :)

Which means they're missing out on this particular idea about the mailman wrapper. The script is small enough it can be described in the docs.

Let's try a grep inside mailman-suite-docs:

grep -r -i wrapper *

no relevant results.

They are small scripts, but describing them in the documentation is problematic because they depend on user names and file system locations, which in turn are distro- or even system-dependent. (Just as an example, some distros use www-data as the web service user, which is needed for the hyperkitty and postorius integrations, while other distros use wwwrun and even others just plain www or something else entirely.)

Providing such wrappers as part of venv or the upstream repository is hence not possible.

This said, nobody prevents you from creating such wrappers for use with your venv installation tailored to your system either, just make sure that you write them up correctly. :)

Also, as is often the way, the documentation could probably be also improved. For instance, the migration documentation says:

This, and in general all, mailman commands should be run as the Mailman user and not as root. Running some of these commands as root can create files owned by root that can’t be read by the Mailman user.

But it doesn't explicitly tell you how to do this. Naturally, as a system administrator installing, maintaining and migrating mailman instances, you should probably know how to run a command as a specific user.

su -s /bin/sh -c "mailman ..." $LIST_USER

and

su -s /bin/sh -c "$PYTHON_BINARY $PATH_TO_MANAGE_PY ..." $WWW_USER

is probably what you want to execute commands either as the mailing list or as the web user, with all these variables being pseudo-variables that you want to fill in/hardcode to fit your system correctly. Putting that in the documentation and especially educating users to not use them in a copy-and-paste manner is difficult, though. Try that and you'll probably have an influx of requests along the lines of "I don't have a variable called $LIST_USER, the command fails to execute!"

Mihai

Mihai Moldovan writes:

Providing such wrappers as part of venv or the upstream repository is hence not possible.

We do provide them as Python scripts, which the wheels install in "some reasonable place" such as $VENV/bin. I imagine this works fine if you install to site-packages for the system Python, although most distros now make that very difficult.

I imagine that these legacy wrappers continue to exist in Debian- family Mailman only because the maintainer is unable to devote time to modernizing the Debian package. IIRC they don't even provide systemd units, but have systemd autogenerate units from /etc/init.d scripts.

-- GNU Mailman consultant (installation, migration, customization) Sirus Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

Thanks. Unfortunately, whereas TIMEOUT is set to 59 and RETRY to 60, I still get the warn... Very weird.

Tried to add these lines before the test in the conf.pyand nothing changes. Should I remove the test on TIMEOUT ?

    # Number of seconds to wait for a worker to finish.                                                                                                                                                                                                                                                                       
    TIMEOUT = conf.get("timeout", 58)

    # Whether to acknowledge unsuccessful tasks.                                                                                                                                                                                                                                                                              
    # This causes failed tasks to be considered delivered, thereby removing them from                                                                                                                                                                                                                                         
    # the task queue. Defaults to False.                                                                                                                                                                                                                                                                                      
    ACK_FAILURES = conf.get("ack_failures", False)

    # Number of seconds to wait for acknowledgement before retrying a task                                                                                                                                                                                                                                                    
    # Only works with brokers that guarantee delivery. Defaults to 60 seconds.                                                                                                                                                                                                                                                
    RETRY = conf.get("retry", 60)

    Q_CLUSTER = {
        'timeout': 300,
        'retry': 360,
        'save_limit': 100,
        'orm': 'default',
    }
    # Verify if retry and timeout settings are correct                                                                                                                                                                                                                                                                        
    if not TIMEOUT or (TIMEOUT > RETRY):
        warn(
            """Retry and timeout are misconfigured. Set retry larger than timeout,                                                                                                                                                                                                                                            
        failure to do so will cause the tasks to be retriggered before completion.                                                                                                                                                                                                                                            
        See https://django-q.readthedocs.io/en/latest/configure.html#retry for details."""
        )