Hackers & Designers - User contributions [en]

Hdsc2024-open-program

2024-06-27T15:34:45Z

Fincato:

HelloHello

Hdsc2024-open-program

2024-06-27T15:26:10Z

Fincato: Created page with "Hello"

Hello

PrePostPrint NL Meetup 2

2024-03-04T10:36:20Z

Fincato:

{{Event
|Name=PrePostPrint NL Meetup 2
|Location=tbc
|Date=2024/05/17
|Time=11:00-17:00
|Type=Meetup
|Web=No
|Print=No
}}
[[File:ppp.png]]

=== Save the date for the next PrePostPrint NL group! ===

PPP is a community of practices around experimental publications made with free software (https://prepostprint.org).

The PPP NL group is imagined as a local satellite of the wider PPP community. While free/libre open source practices seem to be more widely discussed in the context of France and Belgium, we are missing spaces for exchange and converse in the local context of The Netherlands.

If you're curious to explore Free/Libre and Open Source Software (F/LOSS) to make publications and layouts with, or have already worked with these tools and are looking for ways to exchange with others, please join us on 16 February 2024 at the H&D studio!

_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.

[https://signal.group/#CjQKILLW4ogkgaFBJgKnpeKesAcvSVixMEgKpR_Kgdd4MEUWEhD4LsrXPbakq8jJLJbxF1om Join the PPP NL signal group]</code>

_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.

===Schedule===

[tbc]

===Pad===

https://etherpad.hackersanddesigners.nl/p/ppp-nl

Fake it! HDSA Video Documentation

2024-01-29T16:20:50Z

Fincato:

{{Article
|MainNavigation=No
}}

[[File:Jamesvideogame.png|thumb]]

[[Juliette Lizotte]] documented the process of the [https://hackersanddesigners.nl/s/Summer_Academy_2018 Summer Academy 2018].

Find the daily video reports here:

{{#ev:youtube|IFXIj7cK0TQ}}

<htmltag tagname="iframe" width="100%" height="300" scrolling="no" frameborder="no" allow="autoplay" src="https://www.youtube.com/embed/IFXIj7cK0TQ?si=80L-Dm1rTdtz_53_"></htmltag>

{{#ev:youtube|LcdqU4og2sg}}

{{#ev:youtube|fr7kRhhTtSg}}

{{#ev:youtube|ioW9RkHc6mc}}

{{#ev:youtube|yPpaRLFztAc}}

{{#ev:youtube|TYN2XZMem8E}}

{{#ev:youtube|zpq0cFM7vSk}}

{{#ev:youtube|jSMZU4spk7g}}

{{#ev:youtube|5aD-H7Pqg9s}}

{{#ev:youtube|YANEHZd-MbQ}}

{{#ev:youtube|uVqCS7wPUh4}}

[[Category:Publishing]]

Fake it! HDSA Video Documentation

2024-01-29T16:18:53Z

Fincato:

Fake it! HDSA Video Documentation

2024-01-29T16:12:21Z

Fincato:

Test-deployment

2023-10-04T09:41:40Z

Fincato:

HelloHello

Test-deployment

2023-10-04T09:41:11Z

Fincato: Created page with "Hello"

Hello

Server Maintenance

2023-04-24T11:47:40Z

Fincato: Add notes on disk space usage

H&D's VPS usually run on GNU/Linux Debian distribution.

Updating the system once a week (or every two weeks) is kinda good. It's good to cross-check the [https://lists.debian.org/debian-lts-announce/ Debian mailing-list] (debian-lts-announce@lists.debian.org) beforehand to see if anything major needs a security update or particular care.

To upgrade the system, your unix user needs to be in the <code>sudo</code> group. Following the basic process:

* <code>sudo apt update</code> , upgrade local db packages
* <code>sudo apt list --upgradable</code> , show upgradable packages
* <code>sudo apt upgrade</code> , upgrade packages

To list all installed packages, run:

<code>apt list --installed</code>

== Disk space ==
As of 2023-04-24, the main sources of disk space usage are:

* Chatty Pub
* Nextcloud
* Etherpad
* System logs

=== Chatty Pub ===
Currently we are copying the whole Zulip files folder from the VPS where Zulip runs, to the VPS where Chatty Pub runs. The files folder amount to around 4.6 GB.

It would be useful to allocate some time to the project again and look up if Zulip in the meanwhile extended their APIs to allow to fetch files, and eventually if this solves the problem we ran into 2 years ago when trying to do that.

Another alternative option would be to update the codebase of Chatty Pub to detect which files needs to be copied over, instead of mirroring the whole files folder. This though seems harder than the first option.

=== Nextcloud ===
We need to outline and agree on a set of rules on which files and especially how long do they live on Nextcloud. For instance:

* are we using NC for long-term access storage?
* can NC be used for temporarily accessing files online and at some later point remove them (eventually with an archive option)?

if we want to use NC for long-term storage (for eg replacing Google Drive, Dropbox, etc), then it would be wiser to setup another VPS for it, and use that disk space primarily for NC and other sharing / archive purposes.

=== Etherpad ===
The Etherpad database in MySQL is around 1.3 GB. This is mostly due to how Etherpad uses MySQL (it dumps each pad's JSON entry as-is into a MysSQL column, and probably this does not allow MySQL to optimise disk space...).

A possible idea on how to work around this constant growing size are, is to setup an archive system. For instance:

* each pad "lives" for ~ 1 year, after which it is exported as HTML and removed from the MySQL database; see [https://git.vvvvvvaria.org/varia/etherpump etherpump]
** this also means that the pad's welcome text will display the 1 year duration as a reminder, and will share a link to where the archived pad will be found
** we also have to deal with the <code><nowiki>__NOINDEX__</nowiki></code> magic word and the private / public implication of this: if the pad is private, should it be archive after 1 year or not?

=== MySQL ===
Handy command to check the size of each database:<syntaxhighlight lang="shell">
mysql db, check disk size:
SELECT table_schema "database name", sum( data_length + index_length ) / 1024 / 1024 "database size in MB", sum( data_free )/ 1024 / 1024 "free space in MB" FROM information_schema.TABLES GROUP BY table_schema;
</syntaxhighlight>You can also do:<syntaxhighlight lang="shell">
ls -lh /var/lib/mysql
</syntaxhighlight>

=== System Logs ===
We set the system logs to be pruned (or deleted) every 6 day and growing for a maximum of 300 MB:<syntaxhighlight lang="shell">
journalctl --vacuum-time=6d --vacuum-size=300M
</syntaxhighlight>[https://unix.stackexchange.com/a/194058 See ref].

'''Nginx''' logs were also growing up to 68 MB. Not as big as the 800 MB of the system journal, but still much more than the few KB of other programs. You can check and change the logrotate rules for Nginx, for instance, by doing:<syntaxhighlight lang="shell">
vi /etc/logrotate.d/nginx
</syntaxhighlight>Change <code>nginx</code> with any other available log file. [https://stackoverflow.com/a/72109330 See here] for more.{{Article
|MainNavigation=No
}}
[[Category:Maintenance]]

Zulip Maintenance

2023-04-07T20:28:29Z

Fincato: Add debug notes

Some rough notes on running Zulip:

* it requires to run on its own VPS, eg it does not like if you setup other web services (with Nginx) on the same machine
* it needs something slightly more than a basic small VPS, as it runs Python and needs enough CPU and disk space to run decently
* in my experience (maybe due to having left-overs of other web services setup on the same machine, see first point), after each upgrade the HTTPS certificate would break

Given this, the installation instruction are quite clear https://zulip.readthedocs.io/en/stable/production/install.html.

=== Upgrading ===
Refer to the [https://zulip.readthedocs.io/en/stable/production/upgrade-or-modify.html#upgrading-to-a-release official docs]. We're not running Zulip inside Docker or patching Zulip, so the default instructions can be followed as-is.

Steps:

* SSH-login to the VPS
* download the latest version of Zulip: <code>curl -fLO <nowiki>https://download.zulip.com/server/zulip-server-latest.tar.gz</nowiki></code>
* run this command: <code>sudo /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz</code>
* wait for the upgrade to take place and note if any errors is being reported during the process; during this time Zulip will be offline for a few minutes only (hopefully)
* as I'm not sure if the HTTPS problem still happens after a Zulip upgrade, but I remove any left-over of Nginx from the system except Zulip's own files, I'll upgrade this entry after the next upgrade!

Please check [https://zulip.readthedocs.io/en/stable/production/install.html#troubleshooting this Troubleshooting section] in case of problems (how to look up logs, debug, etc).

=== Startup ===
In the case the VPS is being shut down and booted up again, Zulip might have some problems. At last, we figured Zulip's Nginx was clashing with a leftover instance of Apache — both instructed to restart on startup time and both trying to connect to port 80 (Nginx lost).

To debug this, first check what's Zulip status:<syntaxhighlight lang="shell">
supervisorctl status
</syntaxhighlight>Then try to restart Django / and or "everything":<syntaxhighlight lang="shell">
supervisorctl restart zulip-django

supervisorctl restart all
</syntaxhighlight>In case nothing is still working, check Nginx status:<syntaxhighlight lang="shell">
systemctl status nginx
</syntaxhighlight>If you get something like below, it could be Apache2 is still lingering around:<syntaxhighlight lang="shell">
dev.hackersanddesigners.nl nginx[3214]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
dev.hackersanddesigners.nl nginx[3214]: nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)

</syntaxhighlight>Check what's running on port 80 and stop it:<syntaxhighlight lang="shell">
netstat -plant | grep 80

systemctl stop apache2

</syntaxhighlight>Start back Nginx and Zulip should be running fine afterwards:<syntaxhighlight lang="shell">
systemctl start nginx
</syntaxhighlight>{{Article
|MainNavigation=No
}}
[[Category:Maintenance]]

Systemd setup

2023-03-02T14:43:05Z

Fincato: Init

Whether that's good or bad, we're using <code>systemd</code> to manage "services", eg. running a website / web-app through some standard commands.

What this allows is to:

* run a specific program,
* check its status,
* restart it at will,
* tell systemd to start it automatically if we reboot the server,
* tell systemd to restart it automatically if the program crashes for some reasons,
* etc

=== List services ===
You can run this command to list all services managed by systemd:<syntaxhighlight lang="bash">
systemctl list-units --type=service
</syntaxhighlight>This shows everything, and not only the services added by a specific user. As of now (as far as I know, which is little), we're not creating services under a specific user but under root (?), so there might be way to better filter out this list.

=== Add a service ===
To add a new service, follow these steps:

* create a new file under <code>/etc/system/systemd</code>: <code>sudo touch /etc/system/systemd/<service-name>.service</code>
* add the following as a starting point:
* <syntaxhighlight lang="bash">
[Unit]
Description=<service-name>
After=network.target

[Service]
Type=simple
Restart=always
RestartSec=1
User=<user you want the web-app to run under>

WorkingDirectory=<path/to/web-app/>
ExecStart=<command to use to run the web-app>

[Install]
WantedBy=multi-user.target
</syntaxhighlight>This is a very simplified example, please lookup for more detailed references in case you have something more complex.

As you can see in the service example above, we're telling systemd:

* <code>Description</code>: what's the name of the service
* <code>After</code>: when systemd should start the program (eg after the OS network is up and running)
* <code>Type</code>, <code>Restart</code>, <code>User</code>: hopefully, self-explanatory
* <code>WorkingDirectory</code>: tells systemd we want to run our ExecStart command from a specific directory
* <code>WantedBy</code>: I still don't understand what's this exactly, it seems necessary to let systemd know you want this service available
{{Article
|MainNavigation=No
}}
After you created a new service file (or after you updated an existing one), you want to run this command to "refresh" systemd, so that it can see your new service:<syntaxhighlight lang="shell">
sudo systemctl daemon-reload
</syntaxhighlight>Afterwards:

* enable the service (to make it start at system boot / reboot): <code>sudo systemctl enable <service-name>.service</code>

* start the service: <code>sudo systemctl start <service-name>.service</code>
* check its status: <code>sudo systemctl status <service-name>.service</code>
* restart it (in case you modified something in the web-app for instance): <code>sudo systemctl restart <service-name>.service</code>
* stop it: <code>sudo systemctl stop <service-name>.service</code>
* disable the service: <code>sudo systemctl disable <service-name>.service</code>

=== Debugging ===
While running <code>sudo systemctl status <service-name>.service</code> gives you an idea if the service is running fine or not, you don't get much more than that. Depending on your web-app setup (for instance), you might have setup a logging system.

In that case, you can also use the <code>journalctl</code> to access it, by doing:<syntaxhighlight lang="shell">
sudo journalctl -e -u <service-name>.service
</syntaxhighlight>

* <code>-e</code>: stands for "end", and it shows you the end of the logging file, eg the latest entries in the log
* <code>-u</code>: stands for "unit" (I believe), and lets you filter out which logs to display, by setting the service name you want to inspect

[[Category:Infrastructure]]

Systemd setup

2023-03-02T14:02:16Z

Fincato: Created page with "{{Article |MainNavigation=No }}"

Nginx config file

2023-03-02T14:01:41Z

Fincato: Change Category

We use Nginx as HTTP and proxy server. Though each new website might have its own needs, two general pattern are:

* static content
* dynamic content served through a proxy reverse port

=== Workflow ===

* create a new folder under <code>/var/www</code> and put your website code in there
* create a new file under <code>/etc/nginx/sites-available</code> and name it after the website name (or something meaningful), then copy one of the two config setup below as a starting point and customize it based on the needs of your website
* create a symlink to <code>/etc/nginx/sites-enabled</code> by doing:<syntaxhighlight lang="bash">
sudo ln -s /etc/nginx/sites-available/<new-website-config> /etc/nginx/sites-enabled/<new-website-config>
</syntaxhighlight>
* check if there's any nginx config problem with <code>sudo nginx -t</code>

At this point you should have a basic setup working. Except we did not create a secure connection certificate for your website. So far we've been relying on the <code>certbot</code> program, which comes by using [https://letsencrypt.org Let's Encrypt]. So run the following commands:

* <code>sudo certbot</code>, and you should get a list of all available domain names coming from the nginx config files — including the one you just created
* find the domain name of your new website and type its number
* usually we tell Certbot to force redirect any HTTP connection to HTTPS, you can decide this on a per-basis project in case it's not a good idea
* Certbot will update your website nginx config file with some more settings for using HTTPS
* test the website by visiting it!

=== Static Content ===
<syntaxhighlight lang="nginx">
server {

root /var/www/<website-dir>;
index index.html;

server_name <website-url>;
error_page 404 /<custom-404>.html;

location / {
try_files $uri $uri/ =404;
}

// add route to specific subpage
location /<subpage> {
try_files $uri $uri/ =404;
}

// display page as list of files
location /<files-share> {
try_files $uri $uri/ =404;
autoindex on;
}

}
</syntaxhighlight>

=== Dynamic Content served through a Proxy Reverse port ===
<syntaxhighlight lang="nginx">
server {
server_name <website>.com ;

root /var/www/<website>;
access_log /var/log/nginx/<website>.access.log;
error_log /var/log/nginx/<website>.error.log;

location / {
proxy_pass http://127.0.0.1:<port>;
proxy_http_version 1.1;

// example of proxy-headers for a Python application
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_redirect off;
proxy_buffering off;

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $server_name;
}

// example of resource caching
location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico|woff|woff2|ttf)$ {
expires max;
add_header Cache-Control "public, no-transform";
}

}
</syntaxhighlight>

=== Nginx config settings ===
Some common settings to add in <code>/etc/nginx/nginx.conf</code> to help speed up the server and add support for several resource types:<syntaxhighlight lang="nginx">
gzip on;
gzip_proxied expired no-cache no-store private auth;
gzip_min_length 500;
gzip_vary on;
gzip_buffers 4 32k;
gzip_types
application/atom+xml
application/geo+json
application/javascript
application/x-javascript
application/json
application/ld+json
application/manifest+json
application/rdf+xml
application/rss+xml
application/xhtml+xml
application/xml
font/eot
font/otf
font/ttf
image/svg+xml
text/css
text/javascript
text/js
text/plain
text/xml;
gzip_disable "MSIE [1-6]\.";
</syntaxhighlight>
[[Category:Infrastructure]]

MediaWiki Maintenance

2023-03-02T12:44:22Z

Fincato: add clean up instructions.

{{Article
|MainNavigation=No
}}
Upgrading MediaWiki, as it is in general installing it and using it (eg their APIs), is quite annoying. It definitely could be simplified in the process by writing like a Python script (well commented), but so far as I'd used not to upgrade this software so often, it's all manual labour.

The process can be divided in three steps:

* backup the MySQL db and other parts of the system (extensions, images, etc)
* download the newest version of the software, unpacking it, and prepare it
* replace current MediaWiki version with newly prepared version

General, official, [[mediawikiwiki:Manual:Upgrading|reference document]] for upgrading the wiki software.

=== Backup ===
Before starting the backup process (SQL dump), clear any "pending jobs" from the db:

<blockquote>
Use <code>runJobs.php</code> to run all [https://www.mediawiki.org/wiki/Manual:RunJobs.php pending jobs] and clear the queue before performing the upgrade.
</blockquote>

Then backup the MySQL database:<syntaxhighlight lang="bash">
mysqldump --user=<wikidb_user> --password=<wikidb_userpassword> <wiki_db_name> > mw-backup-<yyyy-mm-dd>.sql
</syntaxhighlight>You can find the database's user, password and name under the Database settings in the <code>LocalSettings.php</code> file part of the MediaWiki folder.

The official guide suggests to make also a backup of the image folder, the plugins, the skins, <code>LocalSettings.php</code> etc, go ahead and do that. In this regard, it could be easier to make a backup copy of the entire MediaWiki directory under <code>/var/www/</code>:<syntaxhighlight lang="bash">
sudo cp -r /var/wwww/mediawiki /var/www/mediawiki-bk-<yyyy-mm-dd>
</syntaxhighlight><code><yyyy-mm-dd></code> stands for current date in the form of, for instance, <code>2023-03-02</code>. See [https://en.m.wikipedia.org/wiki/ISO_8601 ISO 8601].

More info on [[mediawikiwiki:Manual:Backing_up_a_wiki|how to back up]] a MediaWiki installation. As well as [[mediawikiwiki:Manual:Restoring_a_wiki_from_backup|how to restore]] a MediaWiki from a backup.

=== Download newest MediaWiki ===
I tend to keep zip / tarballs / installation files in my home folder, and then move to <code>/var/www/</code> accordingly. Therefore:

* <code>cd ~</code>
* fetch newest MediaWiki version, eg: <code>wget <nowiki>https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.tar.gz</nowiki></code> (refer to the [[mediawikiwiki:Manual:Upgrading#Command_line|official docs]] for the correct URL)
* unpack compressed file to a folder of the same name (eg <code>mediawiki-1.39.2</code>) : <code>tar -xvzf mediawiki-1.39.2.tar.gz</code>
* delete compress file: <code>rm mediawiki-1.39.2.tar.gz</code>

=== Upgrade Mediawiki ===
Now we have:

* a backup copy of the current MediaWiki at <code>/var/www/mediawiki-<yyyy-mm-dd></code>
* the newer MediaWiki version at <code>~/mediawiki-<version.number></code>, for example <code>~/mediawiki-1.39.2</code>

Let's first move <code>mediawiki-1.39.2</code> to <code>/var/www:</code><syntaxhighlight lang="bash">
sudo cp -r mediawiki-1.39.2 /var/www/.
</syntaxhighlight>(This operation could be replaced by <code>sudo mv</code> instead, up to you and to your level of comfort in dealing with unix and MediaWiki)

Then we want to copy some of the files in <code>/var/www/mediawiki-<yyyy-mm-dd></code> to <code>/var/www/mediawiki-1.39.2</code>:

* let's move to <code>/var/www/</code>: <code>cd /var/www</code>

* let's copy the image folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/images mediawiki-1.39.2/.</code>
** file and folder settings must be re-set afterwards, run:
*** <code>find ./mediawiki-1.39.2/images -type d -exec chmod 755 {} \;</code>
*** <code>chgrp -R www-data mediawiki-1.39.2/images</code>
* let's copy the extensions folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/extensions mediawiki-1.39.2/.</code>
** To be fair: while this should work, it might break things.Generally speaking, extensions should be kept up-to-date or they might not work with a newer version of MediaWiki. You can see a list of installed extensions by visiting [[Special:Version|this page]] under the section ''Installed extensions'' and manually download each extension to the <code>extensions</code> folder
** I would like to tell you you can simply run a command with PHP's Composer, but it breaks each time I use it (maybe in combination with how MediaWiki works), and it seems a better choice not to fix it... but you can if you want!
* let's copy the settings file: <code>sudo cp mediawiki-<yyyy-mm-dd>/LocalSettings.php mediawiki-1.39.2/.</code>
* let's copy the custom image logo (inside the assets folder): <code>sudo cp -r mediawiki-<yyyy-mm-dd>/resources/assets mediawiki-1.39.2/resources/.</code>
* let's copy the skins folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/skins mediawiki-1.39.2/.</code>

Refer to [[mediawikiwiki:Manual:Upgrading#Other_files|this official doc page]] for more.

After this, we can run the upgrade command:

* <code>cd mediawiki-1.39.2</code>
* <code>php maintenance/update.php</code>

Refer to the [[mediawikiwiki:Manual:Upgrading#Command_line_2|official docs section]] for any eventual problem. Usually this has been working flawlessly.

=== Replace current MediaWiki with newer MediaWiki ===
We have an upgraded version of the MediaWiki software at <code>/var/www/mediawiki-1.39.2</code>, and we want to use it instead of the current one at <code>/var/www/mediawiki</code>:

* move the current version elsewhere: <code>sudo mv mediawiki ~/.</code>
* rename newest version to default name: <code>sudo mv mediawiki-1.39.2 mediawiki</code>

After this, visit [https://wiki.hackersanddesigners.nl wiki.hackersanddesigners.nl] and check if things are working!

=== Clean up ===
When all it's good, remove the following directories:

* <code>sudo rm -rf /var/www/mediawiki-<yyyy-mm-dd></code>
* <code>sudo rm -rf ~/mediawiki-1.39.2</code> (only if you made a copy (<code>cp -r</code>) of the directory from <code>~/.</code> to <code>/var/www/</code>, instead of moving it (<code>mv</code>))

=== Debugging ===
No specific techniques, besides:

* reading the printed error messages on the wiki website
* check the Nginx logs by checking:
** access log: <code>/var/log/nginx/mediawiki.access.log</code>
** error log: <code>/var/log/nginx/mediawiki.error.log</code>

[[Category:Maintenance]]

MediaWiki Maintenance

2023-03-02T12:05:54Z

Fincato: Add debugging

{{Article
|MainNavigation=No
}}
Upgrading MediaWiki, as it is in general installing it and using it (eg their APIs), is quite annoying. It definitely could be simplified in the process by writing like a Python script (well commented), but so far as I'd used not to upgrade this software so often, it's all manual labour.

The process can be divided in three steps:

* backup the MySQL db and other parts of the system
* download the newest version of the software, unpacking it, move it to <code>/var/www/</code>
* make backup copy of current MediaWiki folder in <code>/var/www/</code> and copy to the newer version all plugins from current / previous version

General, official, [[mediawikiwiki:Manual:Upgrading|reference document]] for upgrading the wiki software.

=== Backup ===
Before starting the backup process (SQL dump), clear any "pending jobs" from the db:

<blockquote>
Use <code>runJobs.php</code> to run all [https://www.mediawiki.org/wiki/Manual:RunJobs.php pending jobs] and clear the queue before performing the upgrade.
</blockquote>

Then backup the MySQL database:<syntaxhighlight lang="bash">
mysqldump --user=<wikidb_user> --password=<wikidb_userpassword> <wiki_db_name> > mw-backup-<yyyy-mm-dd>.sql
</syntaxhighlight>You can find the database's user, password and name under the Database settings in the <code>LocalSettings.php</code> file part of the MediaWiki folder.

The official guide suggests to make also a backup of the image folder, the plugins, the skins, <code>LocalSettings.php</code> etc, go ahead and do that. In this regard, it could be easier to make a backup copy of the entire MediaWiki directory under <code>/var/www/</code>:<syntaxhighlight lang="bash">
sudo cp -r /var/wwww/mediawiki /var/www/mediawiki-bk-<yyyy-mm-dd>
</syntaxhighlight><code><yyyy-mm-dd></code> stands for current date in the form of, for instance, <code>2023-03-02</code>. See [https://en.m.wikipedia.org/wiki/ISO_8601 ISO 8601].

More info on [[mediawikiwiki:Manual:Backing_up_a_wiki|how to back up]] a MediaWiki installation. As well as [[mediawikiwiki:Manual:Restoring_a_wiki_from_backup|how to restore]] a MediaWiki from a backup.

=== Download newest MediaWiki ===
I tend to keep zip / tarballs / installation files in my home folder, and then move to <code>/var/www/</code> accordingly. Therefore:

* <code>cd ~</code>
* fetch newest MediaWiki version, eg: <code>wget <nowiki>https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.tar.gz</nowiki></code> (refer to the [[mediawikiwiki:Manual:Upgrading#Command_line|official docs]] for the correct URL)
* unpack compressed file to a folder of the same name (eg <code>mediawiki-1.39.2</code>) : <code>tar -xvzf mediawiki-1.39.2.tar.gz</code>
* delete compress file: <code>rm mediawiki-1.39.2.tar.gz</code>

=== Upgrade Mediawiki ===
Now we have:

* a backup copy of the current MediaWiki at <code>/var/www/mediawiki-<yyyy-mm-dd></code>
* the newer MediaWiki version at <code>~/mediawiki-<version.number></code>, for example <code>~/mediawiki-1.39.2</code>

Let's first move <code>mediawiki-1.39.2</code> to <code>/var/www:</code><syntaxhighlight lang="bash">
sudo cp -r mediawiki-1.39.2 /var/www/.
</syntaxhighlight>Then we want to copy some of the files in <code>/var/www/mediawiki-<yyyy-mm-dd></code> to <code>/var/www/mediawiki-1.39.2</code>:

* let's move to <code>/var/www/</code>: <code>cd /var/www</code>

* let's copy the image folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/images mediawiki-1.39.2/.</code>
** file and folder settings must be re-set afterwards, run:
*** <code>find ./mediawiki-1.39.2/images -type d -exec chmod 755 {} \;</code>
*** <code>chgrp -R www-data mediawiki-1.39.2/images</code>
* let's copy the extensions folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/extensions mediawiki-1.39.2/.</code>
** To be fair: while this should work, it might break things.Generally speaking, extensions should be kept up-to-date or they might not work with a newer version of MediaWiki. You can see a list of installed extensions by visiting [[Special:Version|this page]] under the section ''Installed extensions'' and manually download each extension to the <code>extensions</code> folder
** I would like to tell you you can simply run a command with PHP's Composer, but it breaks each time I use it (maybe in combination with how MediaWiki works), and it seems a better choice not to fix it... but you can if you want!
* let's copy the settings file: <code>sudo cp mediawiki-<yyyy-mm-dd>/LocalSettings.php mediawiki-1.39.2/.</code>
* let's copy the custom image logo (inside the assets folder): <code>sudo cp -r mediawiki-<yyyy-mm-dd>/resources/assets mediawiki-1.39.2/resources/.</code>
* let's copy the skins folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/skins mediawiki-1.39.2/.</code>

Refer to [[mediawikiwiki:Manual:Upgrading#Other_files|this official doc page]] for more.

After this, we can run the upgrade command:

* <code>cd mediawiki-1.39.2</code>
* <code>php maintenance/update.php</code>

Refer to the [[mediawikiwiki:Manual:Upgrading#Command_line_2|official docs section]] for any eventual problem. Usually this has been working flawlessly.

=== Replace current MediaWiki with newer MediaWiki ===
We have an upgraded version of the MediaWiki software at <code>/var/www/mediawiki-1.39.2</code>, and we want to use it instead of the current one at <code>/var/www/mediawiki</code>:

* move the current version elsewhere: <code>sudo mv mediawiki ~/.</code>
* rename newest version to default name: <code>sudo mv mediawiki-1.39.2 mediawiki</code>

After this, visit [https://wiki.hackersanddesigners.nl wiki.hackersanddesigners.nl] and check if things are working!

=== Debugging ===
No specific techniques, besides:

* reading the printed error messages on the wiki website
* check the Nginx logs by checking:
** access log: <code>/var/log/nginx/mediawiki.access.log</code>
** error log: <code>/var/log/nginx/mediawiki.error.log</code>

[[Category:Maintenance]]

MediaWiki Maintenance

2023-03-02T12:00:29Z

Fincato: fix blockquote

{{Article
|MainNavigation=No
}}
Upgrading MediaWiki, as it is in general installing it and using it (eg their APIs), is quite annoying. It definitely could be simplified in the process by writing like a Python script (well commented), but so far as I'd used not to upgrade this software so often, it's all manual labour.

The process can be divided in three steps:

* backup the MySQL db and other parts of the system
* download the newest version of the software, unpacking it, move it to <code>/var/www/</code>
* make backup copy of current MediaWiki folder in <code>/var/www/</code> and copy to the newer version all plugins from current / previous version

General, official, [[mediawikiwiki:Manual:Upgrading|reference document]] for upgrading the wiki software.

=== Backup ===
Before starting the backup process (SQL dump), clear any "pending jobs" from the db:

<blockquote>
Use <code>runJobs.php</code> to run all [https://www.mediawiki.org/wiki/Manual:RunJobs.php pending jobs] and clear the queue before performing the upgrade.
</blockquote>

Then backup the MySQL database:<syntaxhighlight lang="bash">
mysqldump --user=<wikidb_user> --password=<wikidb_userpassword> <wiki_db_name> > mw-backup-<yyyy-mm-dd>.sql
</syntaxhighlight>You can find the database's user, password and name under the Database settings in the <code>LocalSettings.php</code> file part of the MediaWiki folder.

The official guide suggests to make also a backup of the image folder, the plugins, the skins, <code>LocalSettings.php</code> etc, go ahead and do that. In this regard, it could be easier to make a backup copy of the entire MediaWiki directory under <code>/var/www/</code>:<syntaxhighlight lang="bash">
sudo cp -r /var/wwww/mediawiki /var/www/mediawiki-bk-<yyyy-mm-dd>
</syntaxhighlight><code><yyyy-mm-dd></code> stands for current date in the form of, for instance, <code>2023-03-02</code>. See [https://en.m.wikipedia.org/wiki/ISO_8601 ISO 8601].

More info on [[mediawikiwiki:Manual:Backing_up_a_wiki|how to back up]] a MediaWiki installation. As well as [[mediawikiwiki:Manual:Restoring_a_wiki_from_backup|how to restore]] a MediaWiki from a backup.

=== Download newest MediaWiki ===
I tend to keep zip / tarballs / installation files in my home folder, and then move to <code>/var/www/</code> accordingly. Therefore:

* <code>cd ~</code>
* fetch newest MediaWiki version, eg: <code>wget <nowiki>https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.tar.gz</nowiki></code> (refer to the [[mediawikiwiki:Manual:Upgrading#Command_line|official docs]] for the correct URL)
* unpack compressed file to a folder of the same name (eg <code>mediawiki-1.39.2</code>) : <code>tar -xvzf mediawiki-1.39.2.tar.gz</code>
* delete compress file: <code>rm mediawiki-1.39.2.tar.gz</code>

=== Upgrade Mediawiki ===
Now we have:

* a backup copy of the current MediaWiki at <code>/var/www/mediawiki-<yyyy-mm-dd></code>
* the newer MediaWiki version at <code>~/mediawiki-<version.number></code>, for example <code>~/mediawiki-1.39.2</code>

Let's first move <code>mediawiki-1.39.2</code> to <code>/var/www:</code><syntaxhighlight lang="bash">
sudo cp -r mediawiki-1.39.2 /var/www/.
</syntaxhighlight>Then we want to copy some of the files in <code>/var/www/mediawiki-<yyyy-mm-dd></code> to <code>/var/www/mediawiki-1.39.2</code>:

* let's move to <code>/var/www/</code>: <code>cd /var/www</code>

* let's copy the image folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/images mediawiki-1.39.2/.</code>
** file and folder settings must be re-set afterwards, run:
*** <code>find ./mediawiki-1.39.2/images -type d -exec chmod 755 {} \;</code>
*** <code>chgrp -R www-data mediawiki-1.39.2/images</code>
* let's copy the extensions folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/extensions mediawiki-1.39.2/.</code>
** To be fair: while this should work, it might break things.Generally speaking, extensions should be kept up-to-date or they might not work with a newer version of MediaWiki. You can see a list of installed extensions by visiting [[Special:Version|this page]] under the section ''Installed extensions'' and manually download each extension to the <code>extensions</code> folder
** I would like to tell you you can simply run a command with PHP's Composer, but it breaks each time I use it (maybe in combination with how MediaWiki works), and it seems a better choice not to fix it... but you can if you want!
* let's copy the settings file: <code>sudo cp mediawiki-<yyyy-mm-dd>/LocalSettings.php mediawiki-1.39.2/.</code>
* let's copy the custom image logo (inside the assets folder): <code>sudo cp -r mediawiki-<yyyy-mm-dd>/resources/assets mediawiki-1.39.2/resources/.</code>
* let's copy the skins folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/skins mediawiki-1.39.2/.</code>

Refer to [[mediawikiwiki:Manual:Upgrading#Other_files|this official doc page]] for more.

After this, we can run the upgrade command:

* <code>cd mediawiki-1.39.2</code>
* <code>php maintenance/update.php</code>

Refer to the [[mediawikiwiki:Manual:Upgrading#Command_line_2|official docs section]] for any eventual problem. Usually this has been working flawlessly.

=== Replace current MediaWiki with newer MediaWiki ===
We have an upgraded version of the MediaWiki software at <code>/var/www/mediawiki-1.39.2</code>, and we want to use it instead of the current one at <code>/var/www/mediawiki</code>:

* move the current version elsewhere: <code>sudo mv mediawiki ~/.</code>
* rename newest version to default name: <code>sudo mv mediawiki-1.39.2 mediawiki</code>

After this, visit [https://wiki.hackersanddesigners.nl wiki.hackersanddesigners.nl] and check if things are working!

=== Debugging ===
[[Category:Maintenance]]

MediaWiki Maintenance

2023-03-02T11:58:19Z

Fincato: init

{{Article
|MainNavigation=No
}}
Upgrading MediaWiki, as it is in general installing it and using it (eg their APIs), is quite annoying. It definitely could be simplified in the process by writing like a Python script (well commented), but so far as I'd used not to upgrade this software so often, it's all manual labour.

The process can be divided in three steps:

* backup the MySQL db and other parts of the system
* download the newest version of the software, unpacking it, move it to <code>/var/www/</code>
* make backup copy of current MediaWiki folder in <code>/var/www/</code> and copy to the newer version all plugins from current / previous version

General, official, [[mediawikiwiki:Manual:Upgrading|reference document]] for upgrading the wiki software.

=== Backup ===
Before starting the backup process (SQL dump), clear any "pending jobs" from the db:

<blockquote>
Use <code>runJobs.php</code> to run all [https://www.mediawiki.org/wiki/Manual:RunJobs.php pending jobs] and clear the queue before performing the upgrade.Then backup the MySQL database:<syntaxhighlight lang="bash">
mysqldump --user=<wikidb_user> --password=<wikidb_userpassword> <wiki_db_name> > mw-backup-<yyyy-mm-dd>.sql
</syntaxhighlight>You can find the database's user, password and name under the Database settings in the <code>LocalSettings.php</code> file part of the MediaWiki folder.

The official guide suggests to make also a backup of the image folder, the plugins, the skins, <code>LocalSettings.php</code> etc, go ahead and do that. In this regard, it could be easier to make a backup copy of the entire MediaWiki directory under <code>/var/www/</code>:<syntaxhighlight lang="bash">
sudo cp -r /var/wwww/mediawiki /var/www/mediawiki-bk-<yyyy-mm-dd>
</syntaxhighlight><code><yyyy-mm-dd></code> stands for current date in the form of, for instance, <code>2023-03-02</code>. See [https://en.m.wikipedia.org/wiki/ISO_8601 ISO 8601].

More info on [[mediawikiwiki:Manual:Backing_up_a_wiki|how to back up]] a MediaWiki installation. As well as [[mediawikiwiki:Manual:Restoring_a_wiki_from_backup|how to restore]] a MediaWiki from a backup.

=== Download newest MediaWiki ===
I tend to keep zip / tarballs / installation files in my home folder, and then move to <code>/var/www/</code> accordingly. Therefore:

* <code>cd ~</code>
* fetch newest MediaWiki version, eg: <code>wget <nowiki>https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.tar.gz</nowiki></code> (refer to the [[mediawikiwiki:Manual:Upgrading#Command_line|official docs]] for the correct URL)
* unpack compressed file to a folder of the same name (eg <code>mediawiki-1.39.2</code>) : <code>tar -xvzf mediawiki-1.39.2.tar.gz</code>
* delete compress file: <code>rm mediawiki-1.39.2.tar.gz</code>

=== Upgrade Mediawiki ===
Now we have:

* a backup copy of the current MediaWiki at <code>/var/www/mediawiki-<yyyy-mm-dd></code>
* the newer MediaWiki version at <code>~/mediawiki-<version.number></code>, for example <code>~/mediawiki-1.39.2</code>

Let's first move <code>mediawiki-1.39.2</code> to <code>/var/www:</code><syntaxhighlight lang="bash">
sudo cp -r mediawiki-1.39.2 /var/www/.
</syntaxhighlight>Then we want to copy some of the files in <code>/var/www/mediawiki-<yyyy-mm-dd></code> to <code>/var/www/mediawiki-1.39.2</code>:

* let's move to <code>/var/www/</code>: <code>cd /var/www</code>

* let's copy the image folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/images mediawiki-1.39.2/.</code>
** file and folder settings must be re-set afterwards, run:
*** <code>find ./mediawiki-1.39.2/images -type d -exec chmod 755 {} \;</code>
*** <code>chgrp -R www-data mediawiki-1.39.2/images</code>
* let's copy the extensions folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/extensions mediawiki-1.39.2/.</code>
** To be fair: while this should work, it might break things.Generally speaking, extensions should be kept up-to-date or they might not work with a newer version of MediaWiki. You can see a list of installed extensions by visiting [[Special:Version|this page]] under the section ''Installed extensions'' and manually download each extension to the <code>extensions</code> folder
** I would like to tell you you can simply run a command with PHP's Composer, but it breaks each time I use it (maybe in combination with how MediaWiki works), and it seems a better choice not to fix it... but you can if you want!
* let's copy the settings file: <code>sudo cp mediawiki-<yyyy-mm-dd>/LocalSettings.php mediawiki-1.39.2/.</code>
* let's copy the custom image logo (inside the assets folder): <code>sudo cp -r mediawiki-<yyyy-mm-dd>/resources/assets mediawiki-1.39.2/resources/.</code>
* let's copy the skins folder: <code>sudo cp -r mediawiki-<yyyy-mm-dd>/skins mediawiki-1.39.2/.</code>

Refer to [[mediawikiwiki:Manual:Upgrading#Other_files|this official doc page]] for more.

After this, we can run the upgrade command:

* <code>cd mediawiki-1.39.2</code>
* <code>php maintenance/update.php</code>

Refer to the [[mediawikiwiki:Manual:Upgrading#Command_line_2|official docs section]] for any eventual problem. Usually this has been working flawlessly.

=== Replace current MediaWiki with newer MediaWiki ===
We have an upgraded version of the MediaWiki software at <code>/var/www/mediawiki-1.39.2</code>, and we want to use it instead of the current one at <code>/var/www/mediawiki</code>:

* move the current version elsewhere: <code>sudo mv mediawiki ~/.</code>
* rename newest version to default name: <code>sudo mv mediawiki-1.39.2 mediawiki</code>

After this, visit [https://wiki.hackersanddesigners.nl wiki.hackersanddesigners.nl] and check if things are working!

=== Debugging ===
[[Category:Maintenance]]

MediaWiki Maintenance

2023-03-02T10:53:49Z

Fincato:

MediaWiki Maintenance

2023-03-02T10:53:25Z

Fincato:

MediaWiki Maintenance

2023-03-02T10:52:41Z

Fincato:

Upgrading MediaWiki, as it is in general installing it and using it (eg their APIs), is quite annoying. It definitely could be simplified in the process by writing like a Python script (well commented), but so far as I'd used not to upgrade this software so often, it's all manual labour.

The process can be divided in three steps:

* backup the MySQL db and other parts of the system
* download the newest version of the software, unpacking it, move it to <code>/var/www/</code>
* make backup copy of current MediaWiki folder in <code>/var/www/</code> and copy to the newer version all plugins from current / previous version

General, official, [[mediawikiwiki:Manual:Upgrading|reference document]] for upgrading the wiki software.

=== Backup ===
Before starting the backup process (SQL dump), clear any "pending jobs" from the db:

{{Blockquote
|text=Use runJobs.php to run all [https://www.mediawiki.org/wiki/Manual:RunJobs.php pending jobs] and clear the queue before performing the upgrade.
|source=https://www.mediawiki.org/wiki/Manual:Upgrading#Clear_pending_jobs
}}

{{Article
|MainNavigation=No
}}
[[Category:Maintenance]]

MediaWiki Maintenance

2023-03-02T10:48:38Z

Fincato: Init

Upgrading MediaWiki, as it is in general installing it and using it (eg their APIs), is quite annoying. It definitely could be simplified in the process by writing like a Python script (well commented), but so far as I'd used not to upgrade this software so often, it's all manual labour.

The process can be divided in three steps:

* backup the MySQL db and other parts of the system
* download the newest version of the software, unpacking it, move it to <code>/var/www/</code>
* make backup copy of current MediaWiki folder in <code>/var/www/</code> and copy to the newer version all plugins from current / previous version

General, official, [[mediawikiwiki:Manual:Upgrading|reference document]] for upgrading the wiki software.

=== Backup ===
Before starting the backup process (SQL dump), clear any "pending jobs" from the db:

{{Article
|MainNavigation=No
}}
[[Category:Maintenance]]

MediaWiki Maintenance

2023-03-02T10:39:02Z

Fincato: Created page with "{{Article |MainNavigation=No }}"

Zulip Maintenance

2023-03-02T10:28:44Z

Fincato: Init

Zulip Maintenance

2023-03-02T10:11:01Z

Fincato: Created page with "{{Article |MainNavigation=No }}"

Nginx config file

2023-03-02T09:52:16Z

Fincato: add category

Nginx config file

2023-03-02T09:50:38Z

Fincato: Add workflow section

Nginx config file

2023-03-02T09:38:23Z

Fincato: Init

We use Nginx as HTTP and proxy server. Though each new website might have its own needs, two general pattern are:

* static content
* dynamic content served through a proxy reverse port

=== Static Content ===
<syntaxhighlight lang="nginx">
server {

root /var/www/<website-dir>;
index index.html;

server_name <website-url>;
error_page 404 /<custom-404>.html;

location / {
try_files $uri $uri/ =404;
}

// add route to specific subpage
location /<subpage> {
try_files $uri $uri/ =404;
}

// display page as list of files
location /<files-share> {
try_files $uri $uri/ =404;
autoindex on;
}

}
</syntaxhighlight>

=== Dynamic Content served through a Proxy Reverse port ===
<syntaxhighlight lang="nginx">
server {
server_name <website>.com ;

root /var/www/<website>;
access_log /var/log/nginx/<website>.access.log;
error_log /var/log/nginx/<website>.error.log;

location / {
proxy_pass http://127.0.0.1:<port>;
proxy_http_version 1.1;

// example of proxy-headers for a Python application
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_redirect off;
proxy_buffering off;

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $server_name;
}

// example of resource caching
location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico|woff|woff2|ttf)$ {
expires max;
add_header Cache-Control "public, no-transform";
}

}
</syntaxhighlight>

=== Nginx config settings ===
Some common settings to add in <code>/etc/nginx/nginx.conf</code> to help speed up the server and add support for several resource types:<syntaxhighlight lang="nginx">
gzip on;
gzip_proxied expired no-cache no-store private auth;
gzip_min_length 500;
gzip_vary on;
gzip_buffers 4 32k;
gzip_types
application/atom+xml
application/geo+json
application/javascript
application/x-javascript
application/json
application/ld+json
application/manifest+json
application/rdf+xml
application/rss+xml
application/xhtml+xml
application/xml
font/eot
font/otf
font/ttf
image/svg+xml
text/css
text/javascript
text/js
text/plain
text/xml;
gzip_disable "MSIE [1-6]\.";
</syntaxhighlight>

Nginx config file

2023-03-02T09:21:08Z

Fincato: Created page with "{{Article |MainNavigation=No }}"

Category:Infrastructure

2023-02-17T12:36:00Z

Fincato: Created page with "{{Special:WhatLinksHere/Category:Infrastructure}}"

Category:Maintenance

2023-02-17T12:35:35Z

Fincato: Created page with "{{Special:WhatLinksHere/Category:Maintenance}}"

Mlmmj mailing-list setup

2023-02-17T12:33:30Z

Fincato: update disclaimer

This is a reference guide to setup the [http://mlmmj.org/ mlmm] mailing list software on a Debian machine.

''This guide is still a draft version for now, put together by transcribing my log notes and using memory; the mailing list setup is 95% going to work, but there are other details I cannot swear upon (yet). I plan to reproduce the whole process on another VPS soon and double check the steps I reported here''.

UPDATE: after writing this guide around 1 year ago, I still did not setup mlmmj on a new VPS, so please use this and the [http://mlmmj.org/docs/readme-postfix/ official installation notes] from mlmmj (and as usual with Linux, pray the computer gods).
== Prerequisites ==

* A basic email server using <code>postfix</code>; see ''Postfix Setup'' for more
* MX and A records of your list domain name correctly setup in your DNS settings
== Installation ==

<code>mlmmj</code> is a CLI program written in <code>C</code>: fast, tiny and to the point. It can be “extended” by writing bash script or such when necessary (eg for batch subscription or unsubscription). List configuration is done by using text files, it’s all pretty unix-y. OK cool.

Check and upgrade Debian system:

<pre>sudo apt-get update && apt-get upgrade</pre>
Then install <code>mlmmj</code>:

<pre>sudo apt-get install mlmmj</pre>
This creates a <code>spool</code> directory for it under <code>/var/spool/mlmmj</code>. Under <code>/var/spool</code> you usually find also the <code>mail</code> and <code>postfix</code> directory, in Debian systems.

As per <code>mlmmj</code> [http://mlmmj.org/docs/readme-postfix/ recommendation], let’s make a <code>mlmmj</code> system user:

<pre>sudo adduser mlmmj --system --home /var/spool/mlmmj --disabled-password --disabled-login</pre>
We set the following options:

* <code>--system</code>, we create it as a system user as it has no password and no login, because this user acts an automatic process
* <code>--home <path></code>, we set the user’s home directory to mlmmj’s spool directory, instead of the usual <code>home/mlmmj</code>
* <code>--disabled-password</code>, no password
* <code>--disabled-login</code>, no login

The above settings are also done to set the least amount of privilegies to the mlmmj user.

Let’s set the spool directory to be owned by <code>mlmmj</code>:

<pre>sudo chown -R mlmmj /var/spool/mlmmj/</pre>
And finally we make a new <code>systemd</code> entry:

<pre>sudo vi /etc/systemd/system/mlmmj.service</pre>
with the following config, taken from https://github.com/tchapi/mlmmj-service-wrapper/blob/master/mlmmj.service

<pre>[Unit]
Description=This script provides a simple wrapper for mlmmj run as a daemon
After=syslog.target network.target

[Service]
User=root
Type=forking
ExecStart=/usr/bin/mlmmj-maintd -d /var/spool/mlmmj

[Install]
WantedBy=multi-user.target</pre>
Let’s start the service:

<pre>sudo systemctl start mlmmj</pre>
Before testing out our new setup, we need to make some adjustments to <code>postfix</code>.

In <code>/etc/postfix/main.cf</code>, make sure to have configured a ''recipient delimiter'':

<pre>recipient_delimiter = +</pre>
And that our ''transport maps'' are the following:

<pre>virtual_alias_maps = hash:/etc/postfix/virtual
transport_maps = hash:/etc/postfix/transport
mlmmj_destination_recipient_limit = 1</pre>
In <code>/etc/postfix/virtual</code> we set the following line for each list we want to use:

<pre>test@lists.hackersanddesigners.nl lists.hackersanddesigners.nl--test@localhost.mlmmj
news@lists.hackersanddesigners.nl lists.hackersanddesigners.nl--news@localhost.mlmmj</pre>
where: - <code>test</code> or <code>news</code> is replaced with the name of the list - <code>lists.hackersanddesigners.nl</code> with the domain name we want to use (and setup earlier in our DNS). - <code>localhost.mlmmj</code> is a dummy domain used by <code>mlmmj</code> to connect this virtual alias to mlmmj transports

For example:

<pre>flower@lists.acidgreen.nl lists.acidgreen.nl--flower@localhost.mlmmj</pre>
We do the same in <code>/etc/postfix/transport</code>, by adding the following line:

<pre>lists.hackersanddesigners.nl--test@localhost.mlmmj mlmmj:test</pre>
and replacing:

* <code>lists.hackersanddesigners.nl</code> to the domain we want to use
* <code>test</code> to the list name

After, let’s compile these two files to a format that <code>postfix</code> likes more, and reload <code>postfix</code>:

<pre>sudo postmap virtual
sudo postmap transport
sudo postfix reload</pre>
Lastly, let’s add a config line to the end of <code>/etc/postfix/master.cf</code>

<pre># mlmmj mailing lists
mlmmj unix - n n - - pipe
flags=DORhu user=mlmmj argv=/usr/bin/mlmmj-receive -F -L /var/spool/mlmmj/$nexthop</pre>
this tells <code>postfix</code> to process incoming emails with a script command (<code>mlmmj-receive</code>) ran by the <code>mlmmj</code> user, and to use certain flags (other settings useful for <code>mlmmj</code>).

The script will send incoming emails to the <code>mlmmj</code> spool directory (<code>/var/spool/mlmmj</code>) in order to process them: if the email (sender) is trying to post to the list, and has access to it, the message is posted and being sent to every other address in that list; if the email asks to unsubscribe its sender, <code>mlmmj</code> will do that, etc.

We can now create a test list and see if all works!
== Commands ==

=== Make a list ===

TODO: I think that because we setup a <code>systemd</code> process for <code>mlmmj</code>, then <code>mlmmj</code> asks us to run it not with <code>mlmmj-<command></code> but with <code>/usr/bin/mlmmj-<command></code>. Get a grip on why it’s like this…

<pre>sudo /usr/bin/mlmmj-make-ml -c mlmmj -L <list-name> -a</pre>
we create a new list using the <code>mlmmj-make-ml</code> command, and use:

* <code>-c</code>, to set the user who will ''own'' the new list directory under <code>/var/spool/mlmmj</code> (eg <code>/var/spool/mlmmj/test-list</code>)
* <code>-L</code>, to set the list name

get list of subscribers:
=== List subscribers ===

<pre>sudo /usr/bin/mlmmj-list -L <list-name></pre>
=== Subscribe and unsubscribe from and to a list ===

To subscribe, send an email to <code><list-name>+subscribe@lists.hackersanddesigners.nl</code>. To unsubscribe, send an email to <code><list-name>+unsubscribe@lists.hackersanddesigners.nl</code>.
[[Category:Infrastructure]]

Mailing-list Maintenance

2023-02-17T12:29:25Z

Fincato: add link to mlmmj setup

The mailing-list runs through a software called [http://mlmmj.org mlmmj] (Mailing List Management Made Joyful). It's a small C program that works on text files, ultra unix (or Linux?) in the approach.

There's no real maintenance that so far has been needed in the functioning of the software, except sometimes debugging a new post not being published to the list (that was the case of re-opening a VPS port rather than the software itself).

See how to setup [[Mlmmj mailing-list setup|mlmmj from scratch]].

== Adding or removing email does not work ==
Usually adding and removing a new email to the list should happen by simply sending... an email to the list. Sometimes, probably due to moving the list of subscribers to this new setup (the shell script to bulk-import the email address might have added extra "invisible" characters to each email?), this automatic operation does not work.

A first operation should be to run the following command:<syntaxhighlight lang="shell">
ADDRESS=$1
LIST=$2

echo "removing $ADDRESS from $LIST list"
sudo /usr/bin/mlmmj-unsub -L /var/spool/mlmmj/$LIST -a $ADDRESS

echo "checking if address has actually been fully removed..."
sudo rg "$ADDRESS" /var/spool/mlmmj/$LIST/subscribers.d/
</syntaxhighlight>(replace <code>rg</code> with <code>grep</code> if you don't have it installed)

What the above does is to remove the given address from the given list and then grep through all the files inside the subscribers folder to check if it's still there. Optimally it should not!

If it does still, you need to:

* <code>cd</code> to <code>/var/spool/mlmmj/<LIST>/subscribers.d/</code>
* open the correct file (files inside this folder are organized one per each letter of the alphabet) based on the first letter of the email address you need to remove
* remove the line of the email address and save the file

Yes it's a bit of a manual labor. The mistake has already been done. It would be handy to write a new script (maybe not in bash but in Python) to re-import all the email addresses without these possible extra invisible characters (which once I tried to remove and somehow managed —I thought).{{Article
|MainNavigation=No
}}
For posterity, this is the shell script to bulk-import a list of address from a text file, that was found on the mlmmj mailing-list:<syntaxhighlight lang="shell">
INPUT=$1
LIST=$2

if [[ $# -lt 2 ]] ; then
echo "✕ Not enough arguments supplied: please pass INPUT (path/to/file-with-list-of-addresses) and LIST (eg /var/spool/mlmmj/<list>)"
exit 1
fi

while IFS= read -r ADDR; do
sudo /usr/bin/mlmmj-sub -L $LIST -f -q -s -a $ADDR
printf 'imported: %s\n' "$ADDR"
done < $INPUT
</syntaxhighlight>

Mlmmj mailing-list setup

2023-02-17T12:28:32Z

Fincato:

This is a reference guide to setup the [http://mlmmj.org/ mlmm] mailing list software on a Debian machine.

''This guide is still a draft version for now, put together by transcribing my log notes and using memory; the mailing list setup is 95% going to work, but there are other details I cannot swear upon (yet). I plan to reproduce the whole process on another VPS soon and double check the steps I reported here''.
== Prerequisites ==

* A basic email server using <code>postfix</code>; see ''Postfix Setup'' for more
* MX and A records of your list domain name correctly setup in your DNS settings
== Installation ==

<code>mlmmj</code> is a CLI program written in <code>C</code>: fast, tiny and to the point. It can be “extended” by writing bash script or such when necessary (eg for batch subscription or unsubscription). List configuration is done by using text files, it’s all pretty unix-y. OK cool.

Check and upgrade Debian system:

<pre>sudo apt-get update && apt-get upgrade</pre>
Then install <code>mlmmj</code>:

<pre>sudo apt-get install mlmmj</pre>
This creates a <code>spool</code> directory for it under <code>/var/spool/mlmmj</code>. Under <code>/var/spool</code> you usually find also the <code>mail</code> and <code>postfix</code> directory, in Debian systems.

As per <code>mlmmj</code> [http://mlmmj.org/docs/readme-postfix/ recommendation], let’s make a <code>mlmmj</code> system user:

<pre>sudo adduser mlmmj --system --home /var/spool/mlmmj --disabled-password --disabled-login</pre>
We set the following options:

* <code>--system</code>, we create it as a system user as it has no password and no login, because this user acts an automatic process
* <code>--home <path></code>, we set the user’s home directory to mlmmj’s spool directory, instead of the usual <code>home/mlmmj</code>
* <code>--disabled-password</code>, no password
* <code>--disabled-login</code>, no login

The above settings are also done to set the least amount of privilegies to the mlmmj user.

Let’s set the spool directory to be owned by <code>mlmmj</code>:

<pre>sudo chown -R mlmmj /var/spool/mlmmj/</pre>
And finally we make a new <code>systemd</code> entry:

<pre>sudo vi /etc/systemd/system/mlmmj.service</pre>
with the following config, taken from https://github.com/tchapi/mlmmj-service-wrapper/blob/master/mlmmj.service

<pre>[Unit]
Description=This script provides a simple wrapper for mlmmj run as a daemon
After=syslog.target network.target

[Service]
User=root
Type=forking
ExecStart=/usr/bin/mlmmj-maintd -d /var/spool/mlmmj

[Install]
WantedBy=multi-user.target</pre>
Let’s start the service:

<pre>sudo systemctl start mlmmj</pre>
Before testing out our new setup, we need to make some adjustments to <code>postfix</code>.

In <code>/etc/postfix/main.cf</code>, make sure to have configured a ''recipient delimiter'':

<pre>recipient_delimiter = +</pre>
And that our ''transport maps'' are the following:

<pre>virtual_alias_maps = hash:/etc/postfix/virtual
transport_maps = hash:/etc/postfix/transport
mlmmj_destination_recipient_limit = 1</pre>
In <code>/etc/postfix/virtual</code> we set the following line for each list we want to use:

<pre>test@lists.hackersanddesigners.nl lists.hackersanddesigners.nl--test@localhost.mlmmj
news@lists.hackersanddesigners.nl lists.hackersanddesigners.nl--news@localhost.mlmmj</pre>
where: - <code>test</code> or <code>news</code> is replaced with the name of the list - <code>lists.hackersanddesigners.nl</code> with the domain name we want to use (and setup earlier in our DNS). - <code>localhost.mlmmj</code> is a dummy domain used by <code>mlmmj</code> to connect this virtual alias to mlmmj transports

For example:

<pre>flower@lists.acidgreen.nl lists.acidgreen.nl--flower@localhost.mlmmj</pre>
We do the same in <code>/etc/postfix/transport</code>, by adding the following line:

<pre>lists.hackersanddesigners.nl--test@localhost.mlmmj mlmmj:test</pre>
and replacing:

* <code>lists.hackersanddesigners.nl</code> to the domain we want to use
* <code>test</code> to the list name

After, let’s compile these two files to a format that <code>postfix</code> likes more, and reload <code>postfix</code>:

<pre>sudo postmap virtual
sudo postmap transport
sudo postfix reload</pre>
Lastly, let’s add a config line to the end of <code>/etc/postfix/master.cf</code>

<pre># mlmmj mailing lists
mlmmj unix - n n - - pipe
flags=DORhu user=mlmmj argv=/usr/bin/mlmmj-receive -F -L /var/spool/mlmmj/$nexthop</pre>
this tells <code>postfix</code> to process incoming emails with a script command (<code>mlmmj-receive</code>) ran by the <code>mlmmj</code> user, and to use certain flags (other settings useful for <code>mlmmj</code>).

The script will send incoming emails to the <code>mlmmj</code> spool directory (<code>/var/spool/mlmmj</code>) in order to process them: if the email (sender) is trying to post to the list, and has access to it, the message is posted and being sent to every other address in that list; if the email asks to unsubscribe its sender, <code>mlmmj</code> will do that, etc.

We can now create a test list and see if all works!
== Commands ==

=== Make a list ===

TODO: I think that because we setup a <code>systemd</code> process for <code>mlmmj</code>, then <code>mlmmj</code> asks us to run it not with <code>mlmmj-<command></code> but with <code>/usr/bin/mlmmj-<command></code>. Get a grip on why it’s like this…

<pre>sudo /usr/bin/mlmmj-make-ml -c mlmmj -L <list-name> -a</pre>
we create a new list using the <code>mlmmj-make-ml</code> command, and use:

* <code>-c</code>, to set the user who will ''own'' the new list directory under <code>/var/spool/mlmmj</code> (eg <code>/var/spool/mlmmj/test-list</code>)
* <code>-L</code>, to set the list name

get list of subscribers:
=== List subscribers ===

<pre>sudo /usr/bin/mlmmj-list -L <list-name></pre>
=== Subscribe and unsubscribe from and to a list ===

To subscribe, send an email to <code><list-name>+subscribe@lists.hackersanddesigners.nl</code>. To unsubscribe, send an email to <code><list-name>+unsubscribe@lists.hackersanddesigners.nl</code>.
[[Category:Infrastructure]]

Mlmmj mailing-list setup

2023-02-17T12:27:55Z

Fincato: fix spacing maybe

This is a reference guide to setup the [http://mlmmj.org/ mlmm] mailing list software on a Debian machine.

''This guide is still a draft version for now, put together by transcribing my log notes and using memory; the mailing list setup is 95% going to work, but there are other details I cannot swear upon (yet). I plan to reproduce the whole process on another VPS soon and double check the steps I reported here''.
== Prerequisites ==

* A basic email server using <code>postfix</code>; see ''Postfix Setup'' for more
* MX and A records of your list domain name correctly setup in your DNS settings
== Installation ==

<code>mlmmj</code> is a CLI program written in <code>C</code>: fast, tiny and to the point. It can be “extended” by writing bash script or such when necessary (eg for batch subscription or unsubscription). List configuration is done by using text files, it’s all pretty unix-y. OK cool.

Check and upgrade Debian system:

<pre>sudo apt-get update && apt-get upgrade</pre>
Then install <code>mlmmj</code>:

<pre>sudo apt-get install mlmmj</pre>
This creates a <code>spool</code> directory for it under <code>/var/spool/mlmmj</code>. Under <code>/var/spool</code> you usually find also the <code>mail</code> and <code>postfix</code> directory, in Debian systems.

As per <code>mlmmj</code> [http://mlmmj.org/docs/readme-postfix/ recommendation], let’s make a <code>mlmmj</code> system user:

<pre>sudo adduser mlmmj --system --home /var/spool/mlmmj --disabled-password --disabled-login</pre>
We set the following options:

* <code>--system</code>, we create it as a system user as it has no password and no login, because this user acts an automatic process
* <code>--home <path></code>, we set the user’s home directory to mlmmj’s spool directory, instead of the usual <code>home/mlmmj</code>
* <code>--disabled-password</code>, no password
* <code>--disabled-login</code>, no login

The above settings are also done to set the least amount of privilegies to the mlmmj user.

Let’s set the spool directory to be owned by <code>mlmmj</code>:

<pre>sudo chown -R mlmmj /var/spool/mlmmj/</pre>
And finally we make a new <code>systemd</code> entry:

<pre>sudo vi /etc/systemd/system/mlmmj.service</pre>
with the following config, taken from https://github.com/tchapi/mlmmj-service-wrapper/blob/master/mlmmj.service

<pre>[Unit]
Description=This script provides a simple wrapper for mlmmj run as a daemon
After=syslog.target network.target

[Service]
User=root
Type=forking
ExecStart=/usr/bin/mlmmj-maintd -d /var/spool/mlmmj

[Install]
WantedBy=multi-user.target</pre>
Let’s start the service:

<pre>sudo systemctl start mlmmj</pre>
Before testing out our new setup, we need to make some adjustments to <code>postfix</code>.

In <code>/etc/postfix/main.cf</code>, make sure to have configured a ''recipient delimiter'':

<pre>recipient_delimiter = +</pre>
And that our ''transport maps'' are the following:

<pre>virtual_alias_maps = hash:/etc/postfix/virtual
transport_maps = hash:/etc/postfix/transport
mlmmj_destination_recipient_limit = 1</pre>
In <code>/etc/postfix/virtual</code> we set the following line for each list we want to use:

<pre>test@lists.hackersanddesigners.nl lists.hackersanddesigners.nl--test@localhost.mlmmj
news@lists.hackersanddesigners.nl lists.hackersanddesigners.nl--news@localhost.mlmmj</pre>
where: - <code>test</code> or <code>news</code> is replaced with the name of the list - <code>lists.hackersanddesigners.nl</code> with the domain name we want to use (and setup earlier in our DNS). - <code>localhost.mlmmj</code> is a dummy domain used by <code>mlmmj</code> to connect this virtual alias to mlmmj transports

For example:

<pre>flower@lists.acidgreen.nl lists.acidgreen.nl--flower@localhost.mlmmj</pre>
We do the same in <code>/etc/postfix/transport</code>, by adding the following line:

<pre>lists.hackersanddesigners.nl--test@localhost.mlmmj mlmmj:test</pre>
and replacing:

* <code>lists.hackersanddesigners.nl</code> to the domain we want to use
* <code>test</code> to the list name

After, let’s compile these two files to a format that <code>postfix</code> likes more, and reload <code>postfix</code>:

<pre>sudo postmap virtual
sudo postmap transport
sudo postfix reload</pre>
Lastly, let’s add a config line to the end of <code>/etc/postfix/master.cf</code>

<pre># mlmmj mailing lists
mlmmj unix - n n - - pipe
flags=DORhu user=mlmmj argv=/usr/bin/mlmmj-receive -F -L /var/spool/mlmmj/$nexthop</pre>
this tells <code>postfix</code> to process incoming emails with a script command (<code>mlmmj-receive</code>) ran by the <code>mlmmj</code> user, and to use certain flags (other settings useful for <code>mlmmj</code>).

The script will send incoming emails to the <code>mlmmj</code> spool directory (<code>/var/spool/mlmmj</code>) in order to process them: if the email (sender) is trying to post to the list, and has access to it, the message is posted and being sent to every other address in that list; if the email asks to unsubscribe its sender, <code>mlmmj</code> will do that, etc.

We can now create a test list and see if all works!
== Commands ==

=== Make a list ===

TODO: I think that because we setup a <code>systemd</code> process for <code>mlmmj</code>, then <code>mlmmj</code> asks us to run it not with <code>mlmmj-<command></code> but with <code>/usr/bin/mlmmj-<command></code>. Get a grip on why it’s like this…

<pre>sudo /usr/bin/mlmmj-make-ml -c mlmmj -L <list-name> -a</pre>
we create a new list using the <code>mlmmj-make-ml</code> command, and use:

* <code>-c</code>, to set the user who will ''own'' the new list directory under <code>/var/spool/mlmmj</code> (eg <code>/var/spool/mlmmj/test-list</code>)
* <code>-L</code>, to set the list name

get list of subscribers:
=== List subscribers ===

<pre>sudo /usr/bin/mlmmj-list -L <list-name></pre>
=== Subscribe and unsubscribe from and to a list ===

To subscribe, send an email to <code><list-name>+subscribe@lists.hackersanddesigners.nl</code>. To unsubscribe, send an email to <code><list-name>+unsubscribe@lists.hackersanddesigners.nl</code>.

Mlmmj mailing-list setup

2023-02-17T12:26:36Z

Fincato:

{{Article
|MainNavigation=No
}}

This is a reference guide to setup the [http://mlmmj.org/ mlmm] mailing list software on a Debian machine.

''This guide is still a draft version for now, put together by transcribing my log notes and using memory; the mailing list setup is 95% going to work, but there are other details I cannot swear upon (yet). I plan to reproduce the whole process on another VPS soon and double check the steps I reported here''.


== Prerequisites ==

* A basic email server using <code>postfix</code>; see ''Postfix Setup'' for more
* MX and A records of your list domain name correctly setup in your DNS settings


== Installation ==

<code>mlmmj</code> is a CLI program written in <code>C</code>: fast, tiny and to the point. It can be “extended” by writing bash script or such when necessary (eg for batch subscription or unsubscription). List configuration is done by using text files, it’s all pretty unix-y. OK cool.

Check and upgrade Debian system:

<pre>sudo apt-get update && apt-get upgrade</pre>
Then install <code>mlmmj</code>:

<pre>sudo apt-get install mlmmj</pre>
This creates a <code>spool</code> directory for it under <code>/var/spool/mlmmj</code>. Under <code>/var/spool</code> you usually find also the <code>mail</code> and <code>postfix</code> directory, in Debian systems.

As per <code>mlmmj</code> [http://mlmmj.org/docs/readme-postfix/ recommendation], let’s make a <code>mlmmj</code> system user:

<pre>sudo adduser mlmmj --system --home /var/spool/mlmmj --disabled-password --disabled-login</pre>
We set the following options:

* <code>--system</code>, we create it as a system user as it has no password and no login, because this user acts an automatic process
* <code>--home <path></code>, we set the user’s home directory to mlmmj’s spool directory, instead of the usual <code>home/mlmmj</code>
* <code>--disabled-password</code>, no password
* <code>--disabled-login</code>, no login

The above settings are also done to set the least amount of privilegies to the mlmmj user.

Let’s set the spool directory to be owned by <code>mlmmj</code>:

<pre>sudo chown -R mlmmj /var/spool/mlmmj/</pre>
And finally we make a new <code>systemd</code> entry:

<pre>sudo vi /etc/systemd/system/mlmmj.service</pre>
with the following config, taken from https://github.com/tchapi/mlmmj-service-wrapper/blob/master/mlmmj.service

<pre>[Unit]
Description=This script provides a simple wrapper for mlmmj run as a daemon
After=syslog.target network.target

[Service]
User=root
Type=forking
ExecStart=/usr/bin/mlmmj-maintd -d /var/spool/mlmmj

[Install]
WantedBy=multi-user.target</pre>
Let’s start the service:

<pre>sudo systemctl start mlmmj</pre>
Before testing out our new setup, we need to make some adjustments to <code>postfix</code>.

In <code>/etc/postfix/main.cf</code>, make sure to have configured a ''recipient delimiter'':

<pre>recipient_delimiter = +</pre>
And that our ''transport maps'' are the following:

<pre>virtual_alias_maps = hash:/etc/postfix/virtual
transport_maps = hash:/etc/postfix/transport
mlmmj_destination_recipient_limit = 1</pre>
In <code>/etc/postfix/virtual</code> we set the following line for each list we want to use:

<pre>test@lists.hackersanddesigners.nl lists.hackersanddesigners.nl--test@localhost.mlmmj
news@lists.hackersanddesigners.nl lists.hackersanddesigners.nl--news@localhost.mlmmj</pre>
where: - <code>test</code> or <code>news</code> is replaced with the name of the list - <code>lists.hackersanddesigners.nl</code> with the domain name we want to use (and setup earlier in our DNS). - <code>localhost.mlmmj</code> is a dummy domain used by <code>mlmmj</code> to connect this virtual alias to mlmmj transports

For example:

<pre>flower@lists.acidgreen.nl lists.acidgreen.nl--flower@localhost.mlmmj</pre>
We do the same in <code>/etc/postfix/transport</code>, by adding the following line:

<pre>lists.hackersanddesigners.nl--test@localhost.mlmmj mlmmj:test</pre>
and replacing:

* <code>lists.hackersanddesigners.nl</code> to the domain we want to use
* <code>test</code> to the list name

After, let’s compile these two files to a format that <code>postfix</code> likes more, and reload <code>postfix</code>:

<pre>sudo postmap virtual
sudo postmap transport
sudo postfix reload</pre>
Lastly, let’s add a config line to the end of <code>/etc/postfix/master.cf</code>

<pre># mlmmj mailing lists
mlmmj unix - n n - - pipe
flags=DORhu user=mlmmj argv=/usr/bin/mlmmj-receive -F -L /var/spool/mlmmj/$nexthop</pre>
this tells <code>postfix</code> to process incoming emails with a script command (<code>mlmmj-receive</code>) ran by the <code>mlmmj</code> user, and to use certain flags (other settings useful for <code>mlmmj</code>).

The script will send incoming emails to the <code>mlmmj</code> spool directory (<code>/var/spool/mlmmj</code>) in order to process them: if the email (sender) is trying to post to the list, and has access to it, the message is posted and being sent to every other address in that list; if the email asks to unsubscribe its sender, <code>mlmmj</code> will do that, etc.

We can now create a test list and see if all works!


== Commands ==


=== Make a list ===

TODO: I think that because we setup a <code>systemd</code> process for <code>mlmmj</code>, then <code>mlmmj</code> asks us to run it not with <code>mlmmj-<command></code> but with <code>/usr/bin/mlmmj-<command></code>. Get a grip on why it’s like this…

<pre>sudo /usr/bin/mlmmj-make-ml -c mlmmj -L <list-name> -a</pre>
we create a new list using the <code>mlmmj-make-ml</code> command, and use:

* <code>-c</code>, to set the user who will ''own'' the new list directory under <code>/var/spool/mlmmj</code> (eg <code>/var/spool/mlmmj/test-list</code>)
* <code>-L</code>, to set the list name

get list of subscribers:


=== List subscribers ===

<pre>sudo /usr/bin/mlmmj-list -L <list-name></pre>

=== Subscribe and unsubscribe from and to a list ===

To subscribe, send an email to <code><list-name>+subscribe@lists.hackersanddesigners.nl</code>. To unsubscribe, send an email to <code><list-name>+unsubscribe@lists.hackersanddesigners.nl</code>.

Mlmmj mailing-list setup

2023-02-17T12:25:39Z

Fincato:

{{Article
|MainNavigation=No
}}

<code>*-smart</code> outputs better typography (eg straight quotes to curly quotes, etc)


== convert .docx to .md without column-width/pagination ==

<code>pandoc -s input.docx -t markdown-smart -o output.md --wrap=none</code>


== convert all .docx files in current folder ==

<code>find . -name "*.docx" -exec pandoc -s {} -t markdown-smart -o {}.md --wrap=none \;</code>


== convert markdown to mediawiki to clipboard ==

<code>pandoc -s file.txt -t mediawiki | pbcopy</code>


== convert all doc files in current folder to docx ==

<code>textutil -convert docx *.doc</code>

Mlmmj mailing-list setup

2023-02-17T12:25:24Z

Fincato: Created page with "{{Article |MainNavigation=No }}"

Mailing-list Maintenance

2023-02-17T12:22:47Z

Fincato: init

The mailing-list runs through a software called [http://mlmmj.org mlmmj] (Mailing List Management Made Joyful). It's a small C program that works on text files, ultra unix (or Linux?) in the approach.

There's no real maintenance that so far has been needed in the functioning of the software, except sometimes debugging a new post not being published to the list (that was the case of re-opening a VPS port rather than the software itself).

== Adding or removing email does not work ==
Usually adding and removing a new email to the list should happen by simply sending... an email to the list. Sometimes, probably due to moving the list of subscribers to this new setup (the shell script to bulk-import the email address might have added extra "invisible" characters to each email?), this automatic operation does not work.

A first operation should be to run the following command:<syntaxhighlight lang="shell">
ADDRESS=$1
LIST=$2

echo "removing $ADDRESS from $LIST list"
sudo /usr/bin/mlmmj-unsub -L /var/spool/mlmmj/$LIST -a $ADDRESS

echo "checking if address has actually been fully removed..."
sudo rg "$ADDRESS" /var/spool/mlmmj/$LIST/subscribers.d/
</syntaxhighlight>(replace <code>rg</code> with <code>grep</code> if you don't have it installed)

What the above does is to remove the given address from the given list and then grep through all the files inside the subscribers folder to check if it's still there. Optimally it should not!

If it does still, you need to:

* <code>cd</code> to <code>/var/spool/mlmmj/<LIST>/subscribers.d/</code>
* open the correct file (files inside this folder are organized one per each letter of the alphabet) based on the first letter of the email address you need to remove
* remove the line of the email address and save the file

Yes it's a bit of a manual labor. The mistake has already been done. It would be handy to write a new script (maybe not in bash but in Python) to re-import all the email addresses without these possible extra invisible characters (which once I tried to remove and somehow managed —I thought).{{Article
|MainNavigation=No
}}
For posterity, this is the shell script to bulk-import a list of address from a text file, that was found on the mlmmj mailing-list:<syntaxhighlight lang="shell">
INPUT=$1
LIST=$2

if [[ $# -lt 2 ]] ; then
echo "✕ Not enough arguments supplied: please pass INPUT (path/to/file-with-list-of-addresses) and LIST (eg /var/spool/mlmmj/<list>)"
exit 1
fi

while IFS= read -r ADDR; do
sudo /usr/bin/mlmmj-sub -L $LIST -f -q -s -a $ADDR
printf 'imported: %s\n' "$ADDR"
done < $INPUT
</syntaxhighlight>

Mailing-list Maintenance

2023-02-17T11:33:15Z

Fincato: Created page with "{{Article |MainNavigation=No }}"

Etherpad Maintenance

2023-02-17T11:31:42Z

Fincato: /* Setup references */

== List of all public pads ==
You can find an index of all "public" pads at this URL: https://padlist.hackersanddesigners.nl/.

The software running this webpage is available at https://github.com/hackersanddesigners/ether-index.

By public pad, it's meant any pad containing a certain keyword. In our case this is <code><nowiki>__NOINDEX__</nowiki></code>.

== Delete single pad ==
Construct a <code>URL</code> in the form of:

<code><nowiki>https://etherpad.hackersanddesigners.nl/api/1/deletePad?apikey=</nowiki><API-KEY>&padID=<pad-uri></code>

* <code><API-KEY></code> can be found in the root folder of the installed etherpad-lite repo
* <code><pad-uri></code> is the URI of the pad we want to delete, that is the pad's name. For instance for the URL <code><nowiki>https://etherpad.hackersanddesigners.nl/p/test-pad</nowiki></code> the URI is <code>test-pad</code>.

== Setup references ==
* https://github.com/ether/etherpad-lite

* https://github.com/ether/etherpad-lite/wiki/How-to-use-Etherpad-Lite-with-MySQL
* https://github.com/ether/etherpad-lite/wiki/Optimizing-Etherpad
* https://github.com/ether/etherpad-lite/wiki/Converting-from-InnoDB-to-MyISAM

[[Category:Maintenance]]

Etherpad Maintenance

2023-02-17T11:31:29Z

Fincato: add refs

== List of all public pads ==
You can find an index of all "public" pads at this URL: https://padlist.hackersanddesigners.nl/.

The software running this webpage is available at https://github.com/hackersanddesigners/ether-index.

By public pad, it's meant any pad containing a certain keyword. In our case this is <code><nowiki>__NOINDEX__</nowiki></code>.

== Delete single pad ==
Construct a <code>URL</code> in the form of:

<code><nowiki>https://etherpad.hackersanddesigners.nl/api/1/deletePad?apikey=</nowiki><API-KEY>&padID=<pad-uri></code>

* <code><API-KEY></code> can be found in the root folder of the installed etherpad-lite repo
* <code><pad-uri></code> is the URI of the pad we want to delete, that is the pad's name. For instance for the URL <code><nowiki>https://etherpad.hackersanddesigners.nl/p/test-pad</nowiki></code> the URI is <code>test-pad</code>.

== Setup references ==
{{Article
|MainNavigation=No
}}

* https://github.com/ether/etherpad-lite

* https://github.com/ether/etherpad-lite/wiki/How-to-use-Etherpad-Lite-with-MySQL
* https://github.com/ether/etherpad-lite/wiki/Optimizing-Etherpad
* https://github.com/ether/etherpad-lite/wiki/Converting-from-InnoDB-to-MyISAM

[[Category:Maintenance]]

Etherpad Maintenance

2023-02-17T11:12:01Z

Fincato: add padlist

== List of all public pads ==
You can find an index of all "public" pads at this URL: https://padlist.hackersanddesigners.nl/.

The software running this webpage is available at https://github.com/hackersanddesigners/ether-index.

By public pad, it's meant any pad containing a certain keyword. In our case this is <code><nowiki>__NOINDEX__</nowiki></code>.

== Delete single pad ==
Construct a <code>URL</code> in the form of:

<code><nowiki>https://etherpad.hackersanddesigners.nl/api/1/deletePad?apikey=</nowiki><API-KEY>&padID=<pad-uri></code>

* <code><API-KEY></code> can be found in the root folder of the installed etherpad-lite repo
* <code><pad-uri></code> is the URI of the pad we want to delete, that is the pad's name. For instance for the URL <code><nowiki>https://etherpad.hackersanddesigners.nl/p/test-pad</nowiki></code> the URI is <code>test-pad</code>.
{{Article
|MainNavigation=No
}}
[[Category:Maintenance]]

Etherpad Maintenance

2023-02-17T10:49:54Z

Fincato: Created page with "{{Article |MainNavigation=No }}"

Server Maintenance

2023-02-17T10:46:15Z

Fincato: add list

Server Maintenance

2023-02-17T10:43:35Z

Fincato: add category

Server Maintenance

2023-02-17T10:42:52Z

Fincato: init

Server Maintenance

2023-02-17T10:34:41Z

Fincato: Created page with "{{Article |MainNavigation=No }}"

Test Wiki Article

2023-02-15T16:39:22Z

Fincato:

[[File:Screenshot 2022-08-10 at 19.32.42.png|thumb]]
We start off with an intro.

https://hackersanddesigners.nl/s/Tools/p/Chattypub

https://cosmo.hackersanddesigners.nl/

== The problem of scale in Anarchism ==

This paper should be regarded as a continuation of the discussion started in [1] on the problem of scale in Anarchism and the Cybernetic Communism proposal, and as part of a longer forthcoming series of contributions aimed at developing and illustrating different aspects, some more abstract and theoretical and others more concrete, of the Cybernetic Communism idea.

=== From small to large scale anarchism ===

As already discussed in [1], small scale anarchism is a well established system consisting of communes, self-managed workers cooperatives, mutual aid networks, local food production and distribution, shared maker and hacker spaces, organized according to what in the time of the Span- ish Civil War was referred to as libertarian collectivism and libertarian syndicalist socialism.

=== Contra Tiqqun ===

In 2001 the French anarchist collective Tiqqun published a programmatic text called “The Cybernetic Hypothesis”, later published in English translation by Semiotext(e), and just republished in the same series in 2020. In essence, the cybernetic hypothesis is summarized by the statement that “what today is called neoliberalism is best understood as cybernetic capitalism”.

== Networks and complex systems ==

A complex adaptive system (CAS) is “a system in which large networks of com- ponents with no central control and simple rules of operation give rise to complex collective behavior, sophisticated information processing, and adaptation via learning or evolution” [51]. CASes are most concretely realized as biological and ecological systems, but their study is also applied towards social systems. In this paper, we are motivated by the discovery of topological phases in abstract configuration spaces in biological and ecological systems as in [39, 70], interpreting them not just as re- sults not specific to biological or ecological contexts, but speculating more wildly that these results about CASes, and thus containing insights also applicable towards the understanding of society.

=== Mutualistic networks in biological systems ===

As a general caveat, invok- ing nature as a justification for the functioning and aspirations of human society is fraught with dangerous pitfalls, from the social Darwinist appropriations and mis- interpretations of the theory of evolution and natural selection, aimed at justifying and promoting cut-throat capitalist competition as an imitation of a Tennysonian “Nature red in tooth and claw”, to the attempts of the promoters of the capitalist market system to pass off the functioning of markets as some kind of natural law, rather than as a human construct stemming from specific ideological positions.

=== Scale phenomena in complex network ===

The investigation of mutualistic networks in natural ecosystems also reveals interesting properties from the point of view of scale.HelloHello

Test Wiki Article

2023-02-15T16:35:33Z

Fincato:

Hackers and Designers:Sandbox

2023-02-15T13:49:05Z

Fincato:

HelloHello