- clo-devel - mailman3.common-lisp.net

Question about ABCL
by Robert Goldman 15 Nov '17

15 Nov '17

I just tried to send out the announcement of the ASDF 3.1.1 release to armed-bear-devel(a)common-lisp.net, but it bounced back with an unknown user error from common-lisp.net. Any idea what this is about? Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC) 319 N. First Ave., Suite 400 Minneapolis, MN 55401 Voice: (612) 326-3934 Email: rpgoldman(a)SIFT.net

3 3

GitLab.common-lisp.net unavailability: post-mortem
by Erik Huelsmann 01 Oct '17

01 Oct '17

Hi, Last weekend and up to Wednesday, gitlab.common-lisp.net had issues, returning 500 Internal Server Errors while cloning or pulling; additionally the gitlab subdomain was down completely on Sunday. This mail provides an analysis of what happened. There is some context to all this to be started with: common-lisp.net uses the so-called "omnibus" package to run its GitLab install; it's a batteries-included package provided by GitLab, meaning that everything down to OpenSSL, nginx and Ruby are included in the package and installed in a separate - not interfering with the system - location. This omnibus package also comes with its own configuration (script) in the form of a Chef recipe. While the package provides a default configuration which uses an Nginx reverse proxy and default ports for daemons to be accessed over TCP sockets, this default configuration doesn't quite wok on common-lisp.net due to the fact that we use Apache 2.4 as our web-visible reverse proxy. Apache 2.4 also serves a truckload of other services, such as lisppaste, trac, abcl.org, cliki.net, darcsweb.cgi, etc. Due to this entanglement of Apache, we can't just replace it with nginx. Also, due to the large number of reverse-proxied services, not all standard ports for GitLab's configuration are open. This isn't a problem, because GitLab offers the ability to configure site-local deviations from the defaults configuration as input for the Chef recipe. We have succesfully been running with a configuration like this since GitLab 7.(something). The current GitLab version is 10.0. In its evolution from version 7 to version 10, gitlab started out with "Unicorn" based rails workers (a standard Rails setup). As demand grew, a custom webserver was developed (gitlab-git-http-server) which addressed Unicorn time-outs with long running "git" processes (clones). In order to support the "simple" setup with just Unicorn, the unicorn and gitlab-git-http-servers were configured to run each on their own port. Around GitLab 8.2, gitlab-git-http-server was renamed to gitlab-workhorse and the configuration keys were renamed with it, although the old config keys were still respected. Our local override contained these gitlab-git-http-server config keys last Sunday due to ports already being taken by other services. As of version 10, the 'gitlab-git-http-server' configuration keys are no longer supported: the configuration *must* now be specified in terms of 'gitlab-workhorse' keys. Last Sunday, when I upgraded the system to the current version (10.0.2) in the morning, I missed this fact, which caused the system to remain unconfigured (and thus unavailable) until I received notification on #common-lisp.net of problems. The cause at that time was quickly determined and the 'gitlab-git-http-server' configuration keys were quickly removed and the system was redeployed and all seemed to work again, after changing the reverse proxy rules to point to gitlab's remaining open ports. On Monday I received more signals of problems; being on a conference with little to no Net access, Mark pitched in, but was unable to determine the cause. When I *did* have access, everything looked fine, so I didn't check any further. Then on Tuesday, I received more signals of problems, but being on the same conference without Net access, still, I wasn't able to do much. On Wednesday morning, with yet more reports of problems, it became apparent that I was checking the web frontend for availability, but that the people reporting issues were actually experiencing problems with clones/pulls/etc. So, the git-over-http component wasn't working. With the actual problem identified and reproduced, it was quickly apparent that due to the removal of the gitlab-git-http-server config keys, 'gitlab-workhorse' was no longer being configured and started. With a bit of trial-and-error, it also turned out that gitlab-workhorse has a default configuration to run over Unix domain sockets; a configuration supported by Nginx, but not by Apache. With the configuration corrected and the system reconfigured, problems were solved by Wednesday noon. In retrospect, the removal of these config keys was in the release notes, so I could have known. It was 22 <PgDown> clicks down, by which time I wasn't alert enough to realise the importance of the deprecation announcement. Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 1

RFC: Future of lisppaste
by Erik Huelsmann 16 Sep '17

16 Sep '17

Hi, In the early days of web popularity, a very nice irc-bot+paste engine was developed, allowing discussion on IRC to be very nicely combined with paste sharing to help the discussion. It was written in lisp and given the nice name of "lisppaste". While the idea was great to start out, in its grand days, the bot even joined over 60 channels(!), it has gradually seen increases in abuse; initially "just" to spam IRC channels (which caused the bot to be removed from all channels, loosing most of its usefulness), later with lots of inappropriate content being posted. Various measures were taken over time to reduce the attractiveness of posting to lisppaste: * disabling of the XML-RPC api (which integrated with emacs!) * removal from the IRC channels * addition of a captcha up to most recently even: * removal of the listing of posts While the last measure was hoped to take care of the last incentive to post to lisppaste, it seems that links to the inappropriate content are posted elsewhere -- eliminating the need to list the pastes. With the majority of pastes being irrelevant to lisppaste's purpose (supporting programmers discussing their code in IRC or other channels), because they're inappropriate content of some kind or another, my question to you all is: What should we do with lisppaste? Should we simply remove it from the web? Should we put it in read-only mode* (so as to maintain the archive of relevant pastes)? Or are there other options? E.g. someone who wants to adopt lisppaste and invest the time and energy to implement measures to fight the spam and implement measures to discourage or disable posting of inappropriate content? * If we put it in read-only mode, it's my opinion that the existing inappropriate content should still be cleaned. Any contributions to that effect would still be greatly appreciated. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 6

Re: Maintenance of closure-html
by Erik Huelsmann 06 Sep '17

06 Sep '17

Hi David, Thanks for the quick response! Elias, looks like you got the job! Could you send us your SSH public key (through admin(a)common-lisp.net) please so I can create a user account for you to maintain the project website at common-lisp.net/project/closure-html ? Thanks! Regards, Erik. On Wed, May 3, 2017 at 7:50 PM, David Lichteblau <david(a)lichteblau.com> wrote: > (Cc: Elias) > > Quoting Erik Huelsmann (ehuels(a)gmail.com) > > You are listed as the current maintainer of closure-html. We (the > > common-lisp.net admins) have been approached by Elias Martenson who > wants > > to take over maintenance. > > He could not reach you (received no response?), so I'm trying to reach > out > > and see if you are ready to share or hand over maintenance. > > > > Please let us know what we can do. > > Sure, go ahead! Thanks for reaching out. > > For the future maintainer -- The canonical repo for closure-html used to > be, until now: > http://repo.or.cz/closure-html.git > > Let's instead move it to > https://github.com/bluelisp/closure-html > > where we have started to collect other projects that could use some > affection by other community members. You should have received an > invite to that team on github. > > We can inform Zach about the repo change once everything is in place. > > > d. > -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 3

Cannot log in as vsedach@common-lisp.net after added SSH key to Gitlab
by Vladimir Sedach 15 Jul '17

15 Jul '17

Hello, I ran into a strange problem: I added a new ed25519 key to authorized_keys2, which worked fine. Then I went to Gitlab web interface and tried adding the ed25519 key, which failed because Gitlab cannot handle ed25519 keys yet. I made a new RSA key and added that in the Gitlab web interface. After this I cannot log into vsedach(a)common-lisp.net with any of the keys that were in authorized_keys2. The error message is "Permission denied (publickey)" so something must have happened to the authorized_keys file. This seems very strange. I do not think I did anything as vsedach(a)common-lisp.net that would break log-ins, which leads me to believe that it was some script in Gitlab. OTOH the new RSA key does not work either, so it might be something I did through TRAMP by accident. Can you please put this SSH key into authorized_keys: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDc+4x1XblOzyfHAzOCbM00FB/VglYg0PvOSL8FuQKQ/ vas(a)t43.lan. Thank you, Vladimir

3 3

common-lisp.net maintenance: ugraded - what's new?
by Erik Huelsmann 15 Jul '17

15 Jul '17

With respect to the regular services, GitLab was already receiving at least one upgrade per month and security upgrades were being installed as they were released by Debian (automatically). With the upgrade, the system is running a recent version of the Debian distribution again (Stretch). Stretch comes with Apache and Nginx versions which support HTTP/2 out of the box and as we were running common-lisp.net on TLS for a long time already, HTTP/2 is now turned on for all common-lisp.net subdomains. Mail transmission has been configured to use the official common-lisp.net certificate. The new distribution comes with a kernel which is recent enough for container support. Among the next steps, we'll research moving to Mailman3, which comes - as an option - in Docker containers and a much more modern web front-end as well as internal architecture. For those who like to know about the migration strategy for the upgrade: over the past weeks we created a copy of the VM running common-lisp.net and other services. On that copy, we ran a script for an automated upgrade. When the upgrade didn't succeed or didn't complete automatically (that is, required manual intervention), we changed the server configuration and the script. This process went on until the upgrade completed successfully and without intervention. Once successful, the configuration was tested and adjusted for the target software versions. The adjusted configuration was automatically installed after the upgrade process today, followed by a reboot to return service. The migration interval of 3 hours was based on the experience gained from this exercise. In the mean time, a separate VM was installed on the IP pointed to by common-lisp.net, ensuring that even if services would temporarily be up during the migration, no users could accidentally access those services. Thank you for your attention! Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

Heads up: common-lisp.net unavailable tomorrow morning (CET)
by Erik Huelsmann 15 Jul '17

15 Jul '17

Due to major maintenance, common-lisp.net will be unavailable tomorrow between 9 and 12am CET on Saturday July 15. Regards, Erik

1 1

Migrating common-lisp.net to Debian Stretch
by Erik Huelsmann 09 Jul '17

09 Jul '17

Hi all, Over the past weeks, I've been working on a migration from our current OS version to the current stable version as recently released by the Debian project (Stretch). While the time hadn't come to migrate earlier, today I found that the GitLab project released its Stretch packages, meaning that now all the third-party prerequisites are in place to migrate. Today I worked to automate the migration and by the end of today, I'm now able to run an automated migration without manual intervention. I'll leave a copy of the current machine running for a few days to see if it remains stable. If all goes well, it's my intent to take common-lisp.net offline for a few hours coming Saturday (Saturday July 15) in order to run the migration script on the live system instead of on a backup. Before the upgrade starts, we'll take a snapshot of the drives and make sure users won't have access to the system during the migration. Although I've run through various tests already and will continue to do more testing over the coming week, the system might have some instabilities in the days after the migration. When you experience any of those, please report here or to the admins (admin@common dash lisp dot net). Thank you for your patience and continued support/use! Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

Working on system upgrade
by Erik Huelsmann 20 Jun '17

20 Jun '17

Hi, It's nearly time for Debian Stretch to be released. When that happens (and GitLab releases packages for it), we want to upgrade the system quickly afterwards. In preparation, I'm working on trial runs for the base OS upgrade. As a consequence, performance may be degraded. To facilitate the upgrade (make it more quick), I reviewed all packages installed on the system with the purpose of removing unused ones. I've removed quite a few packages indeed (from the current production system, that is): all packages related to the X11 (server) have been removed. So have most LaTeX and LuaTeX packages. The idea behind this step is that the access provided by Common-Lisp.net is merely provided to support uploading and maintaining the static html pages -- my assumption is that that has little relationship to being able to start a desktop environment or graphics environment. If you miss packages that you depend on, don't hesitate to speak up. Please explain what you need them for and I'll make them available again. While going over the upgrade process, I'm doing the so-many-th round of configuration cleanup: due to the fact that the host has been managed by multiple people at various times in the past, each with their own approaches to managing the configuration, the configuration can be much more standardized. On each round of maintenance, that's exactly what I've been doing. Configuration is more-and-more getting in line with "how Debian intends it". Let me use this e-mail as an opportunity to ask current and future (co)maintainers to stick to it; it's often a learning curve, but saves a lot of effort on upgrades later on. There will be a pre-notification and some (planned) downtime for the system when the final cut-over arrives. For those interested in how the migration strategy and dress rehearsals work, I'm going over these steps (wash, rinse, repeat -- in other words: over and over until it works): 1. Create LVM writeable snapshots of the VM's volumes 2. Create a new VM on top of these snapshots 3. Start up the new VM with different IP and hostname settings (patched Apache config too) 4. Change the (git-versioned) /etc directory to the new target distribution version branch 5. Run dist-upgrade (and a number of additional steps) 6. Fix the configuration issues found in the resulting installation and commit (to another server) 7. Ditch the copy-VM and go back to (1) This procedure, although it's taking quite a bit of time to run the dist-upgrade, is turning out pretty effective in producing a reproducible upgrade procedure which can be repeated consistently once the production server needs to be upgraded. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 4

Unable to push to f2cl or merge requests
by Raymond Toy 21 May '17

21 May '17

I used to be able to push commits to the master branch all the time. But in the last month or two something has changed and when I try to push a change to master, I get the message: remote: GitLab: You are not allowed to push code to protected branches on this project. To common-lisp.net:f2cl/f2cl.git ! [remote rejected] master -> master (pre-receive hook declined) I see that master is a protected branch. (I don't remember changing that or if it was always protected.) So I created a merge request <https://gitlab.common-lisp.net/f2cl/f2cl/merge_requests/3> <https://gitlab.common-lisp.net/f2cl/f2cl/merge_requests/3> Now it says I have to go find someone with write access to merge the request. Oddly, just a month ago, I successfully merged the requests https://gitlab.common-lisp.net/f2cl/f2cl/merge_requests/2 and https://gitlab.common-lisp.net/f2cl/f2cl/merge_requests/1. As the owner, I would think I have enough rights both to push to the protected branch and to merge my own merge requests. Any ideas? <https://gitlab.common-lisp.net/f2cl/f2cl/merge_requests/3> -- Ray

4 10