DEV Community: Olivier “Ölbaum” Scherler

I’m Looking for a Web UI for a Static Site Generator

Olivier “Ölbaum” Scherler — Fri, 19 Jul 2019 22:25:37 +0000

TL;DR

I’m looking for a web interface to manage content for a static site generator for web sites (not blogs), and I’d love your help to find one.

Story

When I started blogging, WordPress didn’t exist. I used Movable Type, a blogging engine written in Perl, that had the interesting property that while the admin backend was dynamic (CGI), the public front end was all static files, generated or updated as necessary when you posted or someone commented, resulting in a fast web site that could handle a lot of traffic (that’s right, it was a static site generator, over five years before the term started trending.)

Today I would like the same type of software but for simple web sites, not only a blog. A backend that lets people edit the contents with a nice web interface, and and engine that generates static pages out of it, with templates, navigation, etc.

My wish list

The programming language doesn’t matter, I intend to run in in Docker;
The backend and the site generator don’t need to be the same product, as long as I can get the content from the former to the latter;
I want to host it on my own server;
I would like to make web sites, with hierarchical pages, not only a blog (hierarchical pages to control how the navigation is displayed);
A WYSIWYG editor is preferred;
Web-based, so different people can edit the site without sending each other the source files;
Since I’m going to use it to make small web sites for friends, I’d rather the solution to be free and/or open source. At least not a per-site license. Definitely not a SaaS. DEFINITELY not $499 per year.

What I tried

Ghost: Very nice interface, but only for blogging. Regular pages are too basic;
Jekyll Admin: Only works with the Jekyll debug web server, not really suited for production;
Grav: exactly the opposite of what I’m looking for: you have to edit static files and they are served dynamically;
Netlify CMS: seems to have a very convoluted ways of doing simple things.

If anyone has suggestions for me to try, I would be very grateful. Thanks in advance.

Are login forms that ask for your username and password on two different pages more secure?

Olivier “Ölbaum” Scherler — Mon, 25 Feb 2019 12:18:31 +0000

It’s becoming more and more common: instead of a login form where you fill your e-mail or username and your password, you first have to fill your username and submit the form a first time for the password field to appear on the second page (which is often loaded via Ajax, but the fact that the URL doesn’t change doesn’t make the problem disappear).

There is no need to discuss the fact that it’s annoying, but it seems that companies choose to do so because they believe it’s more secure. Is it really? And if so, why?

(Cover image by Del.)

Changing the MySQL root User from auth_socket to Password Authentication Using Ansible

Olivier “Ölbaum” Scherler — Tue, 19 Feb 2019 20:55:26 +0000

MySQL 5.7 introduced a change in which at install time, the root user is configured using the auth_socket authentication plugin. It means that if you start the MySQL client from the shell as root (connecting through the socket, as the name of the plugin implies,) then you’re automatically authenticated, without a password, based on your user ID on the system. It’s a good thing, because it’s secure out of the box and there’s no root password to set.

But sometimes you have a setup where you need an old-style password on the root user. In my case, I wanted to replace a Ubuntu development machine with an up-to-date one, and I wanted to provision it with Ansible. We had a lot of PHP projects in development running on the old machine, and they all connected to MySQL using the root user, so it wasn’t very practical to create a new user to work around the new plugin set-up. Unfortunately, at the time of this writing, the Ansible mysql_user module does not support authentication plugins, and will fail if you try to set a password on the root user.

Updating the Ansible mysql_user module to support the new plugin seemed the right thing to do, but it turned out to be more complicated than I expected. Authentication plugins were introduced in MariaDB, then found their way into MySQL, and the plugin and column names, as well as the syntax to some commands changed a lot between flavours and versions. Thus it’s hard to test your changes, even with the help of Docker.

I finally found a pretty decent workaround using the unaltered Ansible mysql_user module and some SQL commands, and I want to share it here.

Disclaimer: This method has not been extensively tested, and although it work for the author, is likely to be insecure. Use it only on development VMs or in other non-critical situations.

The concept is to first create a new auth_socket user for Ansible to use, and to delete and recreate the root user with a password if it’s using the auth_socket plugin.

At the base of our trick is a task file that we are going to import for all the users we want to alter:

# mysql_setup_user.yml
# 
# Setup a MySQL user, supporting both the mysql_native_password
# and auth_socket plugins.
# 
# Variables used:
# - login_user: auth_socket user to invoke the MySQL client with (default: root)
# - username: user to configure
# - plugin: authentication plugin for username (default: mysql_native_password)
# - password: password for username
# - priv: privileges to grant
# - host: host to grant privileges for

- name: Apply default values
  set_fact:
    actual_login_user: '{{ login_user | default("root") }}'
    actual_plugin: '{{ plugin | default("mysql_native_password") }}'
    actual_host: '{{ host | default("localhost") }}'

# Check existence and authentication plugin of the user to configure
- name: 'Get {{ username }}@{{ actual_host }} user'
  shell: |
    mysql -u {{ actual_login_user }} -p'{{ login_password }}' -NBe 'SELECT plugin FROM mysql.user WHERE Host="{{ actual_host }}" AND User = "{{ username }}"'
  failed_when: no
  changed_when: no
  register: mysql_plugin_output

# User exists if the output of the previous task is not empty
# The auth plugin is the output of the previous task
- name: 'Store {{ username }} user info'
  set_fact:
    user_exists: '{{ mysql_plugin_output.stdout != "" }}'
    user_current_plugin: '{{ mysql_plugin_output.stdout }}'

# If the requested user doesn’t exist and the plugin is mysql_native_password,
# create it using the mysql_user module
- name: 'Create {{ username }} user (if plugin == mysql_native_password)'
  mysql_user:
    login_user: '{{ actual_login_user }}'
    login_password: '{{ login_password }}'
    name: '{{ username }}'
    host: '{{ actual_host }}'
  when: 'actual_plugin == "mysql_native_password" and not user_exists'

# If the requested user doesn’t exist but the plugin is auth_socket,
# then we can’t create it using the mysql_user module, so we resort
# to a shell command
- name: 'Create {{ username }} user (if plugin == auth_socket)'
  shell: |
    mysql -u {{ actual_login_user }} -p'{{ login_password }}' -NBe 'CREATE USER "{{ username }}"@"{{ actual_host }}" IDENTIFIED WITH auth_socket'
  when: 'actual_plugin == "auth_socket" and not user_exists'

# Change the plugin if needed, providing the password if the new plugin
# is mysql_native_password.
# It only supports a clear text password, so use a vault.
- name: 'Alter {{ username }} user to use {{ actual_plugin }}'
  shell: |
    mysql -u {{ actual_login_user }} -p'{{ login_password }}' -NBe 'ALTER USER "{{ username }}"@"{{ actual_host }}" IDENTIFIED WITH {{ actual_plugin }} {% if actual_plugin == "mysql_native_password" %}BY "{{ password }}"{% endif %}'
  when: 'user_current_plugin != actual_plugin'

# If the plugin is mysql_native_password, update the user using Ansible mysql_user,
# to change its password.
- name: 'Update {{ username }} user (if plugin == mysql_native_password)'
  mysql_user:
    login_user: '{{ actual_login_user }}'
    login_password: '{{ login_password }}'
    name: '{{ username }}'
    password: '{{ password }}'
    host: '{{ actual_host }}'
  when: 'actual_plugin == "mysql_native_password"'

# Grant privileges
- name: 'Grant privileges to user {{ username }}'
  mysql_user:
    login_user: '{{ actual_login_user }}'
    login_password: '{{ login_password }}'
    name: '{{ username }}'
    host: '{{ actual_host }}'
    priv: '{{ priv }}'

We are going to use this task file in two plays: one to set-up a new auth_socket user so we can alter the root user, and the other one to actually alter it:

# mysql-root-playbook.yml

- name: Set MySQL root password
  hosts: all
  become: yes

  tasks:
    - name: Create user Ansible for MySQL administration with auth_socket
      user:
        name: 'ansible'
        state: present
        createhome: no

    - name: Setup ansible user
      include_tasks: mysql_setup_user.yml
      vars:
        username: ansible
        login_password: '{{ mysql_root_password }}'
        plugin: auth_socket
        priv: '*.*:ALL,GRANT'

- name: Configure MySQL root user (using user ansible)
  hosts: all
  become: yes
  become_user: ansible

  tasks:
    - name: Setup root user
      include_tasks: mysql_setup_user.yml
      vars:
        login_user: ansible
        login_password: '{{ mysql_root_password }}'
        username: root
        plugin: mysql_native_password
        password: '{{ mysql_root_password }}'
        priv: '*.*:ALL,GRANT'
        host: '{{ item }}'
      with_items:
        - 'localhost'
        - '127.0.0.1'
        - '%'

Now if you set variable mysql_root_password and run the above playbook with ansible-playbook -i hosts.yml mysql-root-playbook.yml (replace hosts.yml with your actual inventory), the following is going to happen:

The first play, as root, will:

Create a new system user, ansible;
Create MySQL user ansible@localhost with plugin auth_socket (no password needed) and full privileges, using the current root user with auth_socket.

The second play, as user ansible will:

See that root@localhost is using plugin auth_socket;
Alter the root user to use mysql_native_password and the desired password.

If you run the playbook again, it will see (as root with the newly set password) that the ansible user is configured as desired, and them as ansible with auth_socket that the root user is configured as desired as well.

Three drawbacks to this method:

It’s quite verbose;
It runs shell commands with the MySQL password for root in the command line;
It will fail if you subsequently change the root password, because it won’t be able to connect as root with a password.

However, this is a workaround intended for development machines, so it doesn’t really matter. On a production machine, you should be perfectly happy with using auth_socket for root@localhost.

Move Android Studio Virtual Devices to Another Hard Drive on a Mac

Olivier “Ölbaum” Scherler — Wed, 06 Feb 2019 10:08:40 +0000

Imagine you’d like to reclaim space on your Mac’s main hard drive by moving your Android Studio Virtual Devices (the phones and tablets you run in the Android Emulator to test your applications). It’s possible, but if you’re lucky like I am, you might run into some hurdles.

It’s easy enough to find out that you should modify either the ANDROID_SDK_ROOT, ANDROID_EMULATOR_HOME, or ANDROID_AVD_HOME environment variables (or even ANDROID_HOME, if you’re unlucky enough to find some really outdated documents). But if you try to set them under Appearance & Behavior > Path Variables in the Android Studio Preferences, because you think it would be a reasonable thing to do, then you might waste a lot of time, because it does not work. And of course, the thousands of documents about how to do it in Windows are of no help at all, and the few that are about the Mac are really, really outdated.

What we want to achieve here is to define the ANDROID_AVD_HOME environment variable in a way that makes it available to applications launched from the Finder. Starting from Mac OS 10.10 (and working at least until 10.14, at the time of this writing), it can be done with launchctl setenv:

launchctl setenv ANDROID_AVD_HOME /Volumes/LargeHDD/Android/avd

To test it without starting Android Studio, you can use Apple’s Script Editor and run this script (however, keep in mind that you must relaunch Script Editor after calling launchctl setenv, in order for it to pick up the changes):

do shell script "echo $ANDROID_AVD_HOME"

Now is a good time to move your Android Virtual Device (AVD) files from ~/.android/avd to their new location (e.g. /Volumes/LargeHDD/Android/avd).

However, you also need to update the .ini files in that folder, because they reference an absolute path to the old location, and if you don’t update it, Android Studio will complain that the INI file is corrupted. For example if you have a file Nexus_5X_API_26.ini in your new /Volumes/LargeHDD/Android/avd folder, edit it (the path property) from:

avd.ini.encoding=UTF-8
path=/Users/olivier/.android/avd/Nexus_5X_API_26.avd
path.rel=avd/Nexus_5X_API_26.avd
target=android-26

avd.ini.encoding=UTF-8
path=/Volumes/LargeHDD/Android/avd/Nexus_5X_API_26.avd
path.rel=avd/Nexus_5X_API_26.avd
target=android-26

You can now launch Android Studio and open the AVD Manager to see that your devices are still there, but we still need to make sure this environment variable is set every time you log in. For that, we are going to create a script, and start it at login using Launchd.

Create the following script at /Users/[YOUR_USER_NAME]/.android_studio_env_vars:

export ANDROID_AVD_HOME='/Volumes/LargeHDD/Android/avd'

launchctl setenv ANDROID_AVD_HOME "$ANDROID_AVD_HOME"

Then create the following PList file at ~/Library/LaunchAgents/user.AndroidStudioEnvVars.plist (you can name it however you like):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>user.AndroidStudioEnvVars</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>/Users/[YOUR_USER_NAME]/.android_studio_env_vars</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

We could just execute launchctl setenv ANDROID_AVD_HOME /Volumes/LargeHDD/Android/avd from the PList, but a script allows us to define other variables, like ANDROID_SDK_ROOT if needed.

Finally, load the PList with:

launchctl load ~/Library/LaunchAgents/user.AndroidStudioEnvVars.plist

The next time you log in or restart, the environment variable should be automatically set, which you can check with:

launchctl getenv ANDROID_SDK_ROOT
# -> /Volumes/LargeHDD/Android/sdk