Worked on a 2nd 2-Minute Tutorial for “Proxy Workflow in Kdenlive”, but I ran into some questions about how it worked, and tabled it.
DEVELOPMENT: VIRTUAL STUDIO PROJECT SITE
Researched/tested customization for YunoHost portal.
I figured out how to replace the two-letter abbreviations with icons for the different applications, which I think is a big improvement in readability (especially since the full name is also included under each).
Tested “Custom Webapp” for static sites and for installing ResourceSpace (standard LAMP applications can be installed this way).
Created updates and/or stub sites for all the static websites.
Testing Shiori and Shaarli again for usability. I kind of wish I had the best expects of each — neither is a really good fit as it is.
Also creating a custom navigation bar (mini-portal) for inclusion on some of the sites that allow it (so far, that’s WordPress and Gitea).
Testing URL shortener applications: YOURLS and LSTU. Although Yourls seems to have a better UI, it doesn’t quite work right, and I settled on LSTU as the better option.
Tested more WordPress plugins.
Discovered that YunoHost does have an app for “Odoo”, under the name “LibreERP” (it used to be called “OpenERP”, after all). After checking some other business apps, I decided I would probably go with LibreERP, especially since I already have some Odoo books, which should apply. That’s a deep rabbit-hole, though. I’m not planning to dive into it yet, but I did add it to my buildout.
RESOURCESPACE TESTING WITH YUNOHOST
Worked on a process for installing ResourceSpace using the Custom Webapp “app” for YunoHost, and also on customization and configuration.
Found a plugin for using S3 object storage for the filestore, although it seems not to work properly, in the end.
Ran a test of synchronizing with on-disk content, using StaticSync.
GIT MIGRATION DESIGN
Studied methods for handling the Library / Episodes repository setup for Lunatics Project. Decided in the end that the best way is to have them in independent repositories, with a symlink to tie the Episode to the Library repo.
Wrote a script to recreate the symlink, which should make it work with either Linux or Windows (untested) platforms.
ANSIBLE PLAYBOOKS SETUP
Found and started updating the Ansible playbook scripts I had collected for managing the old site. Setup Eclipse to manage them.
OLD SITE BACKUP
I found and updated my old Ansible playbook for backing up the old server, and got it to run successfully. So I have a backup of the site now.
I tested automatically scanning 4×6″ storyboard cards with our existing scanner’s automatic document feeder (ADF), and this did not work.
Ordinary ADF scanners in general, don’t seem to be able to handle thicker stock like this.
After some research, I was able to find a $600 machine which can do this, intended as a photo scanner. This looks like a sensible purchase for production, later down the road. It would save a lot of time over scanning the cards individually on the flatbed and having to correct them one-by-one in Gimp. But it’s too much money to do it now.
Reorganized annual reports data for Anansi Spaceworks to use a more chronological approach — gathering all the reports for each year into folders by year. Filed businss partnership tax return (1065).
Got replacement for hybrid battery in red Prius installed, from Hometown Hybrids, after Texas Hybrids told me they didn’t have a refurbished battery in stock. Turns out HH’s warranty is better, anyway.
YunoHost: Final Tests with Custom Webapp and ResourceSpace
YunoHost has turned out to be an unqualified success in all of my testing. Up to yesterday, all the applications I tested were “apps” that had already been prepared for YunoHost. This covered most of my needs.
However, three of my most important existing web applications were NOT represented:
The first two are fairly antiquated solutions and can be neatly replaced by migrating to Gitea, which is packaged for YunoHost. I’ve already written about that, and will be writing more about configuring my Git repos and customizing the look and feel of Gitea for the project.
But what to do about ResourceSpace? I need a working DAMS. There is a packaged DAMS for YunoHost, called “Omeka S”, which I did test. It seems to be quite a powerful solution, and I was surprised that I’d never heard of it before this. But I didn’t feel it was more appropriate for our project than ResourceSpace, and to learn a new DAMS would be a whole new project in itself!
I originally planned to resolve this by simply running ResourceSpace and my static HTML content on a separate droplet VPS, using my old management scripts. This would probably have worked fine, although the rent on two droplets would increase my hosting costs (which are probably going to go up with this transition anyway — I’m installing more demanding applications and need to pay for more RAM and multiple “virtual CPUs” for adequate performance).
But I decided to try for “extra credit” and see if I could migrate the entire site to a single YunoHost server, and save the money on the other server I wouldn’t need.
For that, YunoHost has a “Custom Webapp” App (a.k.a. ‘my_webapp’) which allows for more “hands-on” installations. I have to say, the documentation did not make it entirely clear to me that this is the correct way to install a static webpage. I had some confusion between this package and the stub package for creating new YunoHost apps (called ‘example_ynh’).
In fact, the confusion may not be entirely coincidental — I suspect that using the Custom Webapp to install a package is a good way to learn what installation scripts will be needed to create a new app. I plan to explore that option in the future.
However, the “Custom Webapp” package can handle a bit more than just a static website. It also supports simple LAMP applications, by providing PHP scripting and MySQL database configuration. (I guess, technically, they are now “LNMP” apps, since YunoHost uses the Nginx webserver, but I’m sticking with the more-pronounceable “LAMP” acronym).
My first test was simply to create a test domain and unpack one of my static HTML sites onto it. I used my old CV page (needs an update, but still looks pretty good):
And then, just to prove I can install more than one static site, side-by-side, I also installed a copy of the Lunatics release page on another subdomain:
As you can see, it’s basically indistinguishable from the current release page, which means everything is working. The main distinction is a different URL, and HTTPS support (don’t worry, the URL isn’t changing — I’ll be changing the DNS to point the old URL to the new site, as soon as it’s up).
This worked fine. I only have one complaint about it, which is that I cannot set the directory name for the static site. Instead, I get folders named like “/var/www/my_webapp__2/www” which I find ugly and not mnemonic. I would prefer to use the domain name, the app “label”, or another custom name defined during installation. But this is small potatoes. I just need to have a table somewhere telling me which is which.
Resource Space 9.8
For my next trick, I needed to install Resource Space from scratch (as opposed to just restoring a backup from my old site), into a YunoHost “Custom Webapp” installation.
First, I created a sub-domain for it in YunoHost, then installed the Custom Webapp on that domain. All of the available PHP versions are supported by ResourceSpace, so I just used the newest, PHP 8.0. And then I selected the option to set up a MySQL database for it. Of course, the site needs to be accessible to the public:
I used SVN to get a copy of the 9.8 release on my hard drive and uploaded that to the server (Yes, ResourceSpace is still maintained in SVN, sorry Git fans). I could’ve saved a little time there by unpacking directly on the server, but I prefer to keep a local full-source copy of any software I’m relying on. Not that I don’t trust the corporate SaaS supplier to keep providing source access, but… yeah, who am I kidding, I don’t trust them (the nice thing is, with open source, I don’t have to).
I won’t go into full detail, but I’ll outline some important notes that were specific to getting this working on YunoHost. You do need to log into the CLI on the server to do this.
Most of the requirements were met by YunoHost, but I had to install a few more [EDIT: added mbstring dependency, which I discovered later , 2022-04-03]:
# apt-get install php8.0-gd php8.0-mbstring libimage-exiftool-perl
Note that if PHP libraries are missing, you need to specify which versions you want to install. PHP 8.0 is apparently not the default version in Debian 10, so installing “php-gd” doesn’t do what you want. I think these two were the only ones that were missing, but if you get warning during installation about missing packages, this is how to fix that.
Do NOT follow the Knowledge Base instructions to install the MySQL database. YunoHost has already done that for you. The database name and username will both be ‘my_webapp’ (or ‘my_webapp__#’), and the password will be autogenerated. These credentials will be mailed to the YunoHost admin email address, so you’ll need to check that to get them.
To process resources, ResourceSpace typically calls programs on the command line from PHP. So you need the appropriate programs to do this. I know I will be needing Inkscape and Blender for this:
# apt-get install inkscape blender
It probably should be noted that installing desktop applications like these on a server introduces a number of packages that aren’t normally on servers, and which may be somewhat pointless, since they will never be used in GUI mode. These might be security risks. I’m doing it anyway, because it’s important to me, but you should probably think about the security implications.
There are a few changes needed in the “php.ini” file, which is ‘/etc/php/php-fpm/php.ini‘ [EDIT: I don’t know if this changed or I just got it wrong, but I had to change to ‘/etc/php/8.0/fpm/php.ini‘ on my second installation]. I don’t really understand why there are two configurations for PHP in Debian 10 (“CLI” and “FPM”), but there are. FPM is the one you want.
In, particular, you will need to greatly increase the available upload capacity. I changed the following:
- memory_limit = 512M # Default was 128M
- post_max_size = 2000M # Default was 8M
- upload_max_filesize = 2000M # Default was 2M
(I’m guessing I could’ve used ‘2G here. I’m not actually sure if a size this large is wise, but I do run into large files a lot).
The package needs to be unpacked to ‘/var/www/my_webapp/www‘ (if it is the first Custom Webapp installed, or “my_webapp__#” where “#” is the number of the app — it was actually “my_webapp__3” on my test). Note that the top level directory of the SVN checkout is a folder with the version number, i.e. “9.8” in this case. You don’t want to put that folder into www, but rather, its contents. I’m pretty sure the SVN command they list on their page doesn’t do that correctly, unless I mistyped it. Easily fixed with a ‘mv‘ command, though:
# cd /var/www/my_webapp/www/9.8
# mv * ..
Also, this might be a good time to delete the default ‘index.html’ page that YunoHost installs:
# cd /var/www/my_webapp/www
# rm index.html
Otherwise, you will get this cute kitten, instead of the installer:
The entire folder should be owned by the user ‘my_webapp‘ and group ‘www-data’.
As the instructions tell you, you need to create a new folder ‘filestore‘ in ‘www‘. Then set both that and ‘include’ to fully-open permissions, i.e.:
# cd /var/www/my_webapp/www
# mkdir filestore
# chmod -R 777 filestore include
After this, use YunoHost’s “Services” panel to restart the “PHP” and “Nginx” services. Restarting Nginx may cause the admin interface to hang — just reload it after a couple of minutes, and you may have to login to the admin interface again.
Then you visit the domain you just created, and the Resource Space through-the-web installation panel should appear. If you see some red text on this, it’s telling you about missing packages or bad configuration you need to fix.
Note that the MySQL username, password, and database should have been mailed to you by YunoHost when it set them up. As far as I know, there is no reason to set up a “read-only” connection for this installation. Perhaps it’s for replication, or perhaps we will study this another day.
There’s just a few more things to set up, and then submit, and after a bit, you will get a confirmation that the install worked. If the application files do note have the correct ownership and permissions, as described above, you’ll get a blank page with just the “ResourceSpace” logo on it at this point. Fixing the file ownership (chown) and permissions (chmod) and (possibly) restarting PHP and Nginx services again, should fix it, if that happens.
If this is all working, you will be congratulated…
…and then led to to the login page for your new site:
The little cloud icon in the lower right hand corner is a link back to the YunoHost Portal, this is an overlay that YunoHost places over most apps. Sometimes it is annoying, because it’ll be displayed over an important button. Fortunately, it can be dragged to another part of the window. Took me awhile to discover that! (Also, in the default theme, the icon says “YUNO HOST”, rather than showing this cloud).
After login, you get the page at the top of this article. If you don’t like the background image (it’s a default, provided with the program), you can change it from ResourceSpace’s own administration page).
And that’s it for today…
That’s as far as I got with this test. Actually setting up collections and assets (or “resources”) inside ResourceSpace is a sizable project on its own, but not particular to the YunoHost installation.
It’s likely that I will be installing the “StaticSync” ResourceSpace plugin, which provides synchronization with a collection of resources stored on the filesystem. I am uncertain whether this will eliminate the need for a crawler script of my own. I am also studying the ResourceSpace API, though. The API uses a “RESTful” JSON system, which I think will be easy to wrap with Python’s “requests” module.
This completes my experimental phase with YunoHost, and everything pretty much worked. Better than I expected, in fact, because it seems that I won’t need to maintain a separate droplet for non-YunoHost components (at least, not if I don’t want to).
I will now start from the top, building the real project site on a new droplet.
I discovered some minor errors (or changes?) when I repeated this process using my updated Ansible role for ResourceSpace. I’ve added these corrections with notes in square-brackets, since I’m hoping to use this article for documentation. — Lunatics Project
Russia invaded Ukraine, in one of the most brazen acts of naked aggression I can recall. There are many takes on this, worldwide, and comparisons can certainly be drawn to the past behavior of the United States (as in the Iraq War, which was started under transparently false pretenses by the Bush administration). Others would like to emphasize that the government of Ukraine is far from pristine, but what country isn’t? I don’t think there can be any reasonable justification for what Putin has done, and the pro-Russia arguments all seem like motivated “whataboutism” or some other sophistry.
The main impact on Lunatics Project, though, is that US-Russia relations have tanked, and there are many sanctions being enacted which affect all Russians, not just the ones involved in the war. I am worried that this will negatively impact our production, not just because of the ties to Morevna Project and other people inside Russia who have maintained key software, but also the return of sharply negative views of Russia which make the strong story-ties to the Russian space program in our pilot seem off-tone.
I hope that things will clear up in time, but it’s hard not to think this is going to do some serious and fairly permanent damage to Russia’s standing in the world.
I tried to draft an article about this, and possibly an introductory dedication for the pilot episode, but I didn’t finish the post, and it all seems a little weak in context, now.