Let's improve my "trick" from the last post a little bit, by adding staging and qa.

Below a visualisation, in remote are the symlinks to the mountpoints of the remote directory (e.g. via GVS or SSHFS), in mirror the directories you rsync with first to get the batch file and in batch you store the batch files genearted by rsync.

  • remote
    • prod (symlink)
    • qa (symlink)
    • stg (symlink)
  • mirror
    • prod (dir)
    • qa (dir)
    • stg (dir)
  • batch
    • prod (dir)
    • qa (dir)
    • stg (dir)

vfs-rsync-upload

Creating the directory structure and the symlinks for each project and run the rather long rsync command by hand is al little bit unhandy, so I wrote a little script for that, find it on gitlab.com/criztovyl/vfs-rsync-upload.

Setup a project

To set up the remotes for project (any directory) run the command below.

/path/to/mount is the mount point of the remote directory, dist the directory you want to upload and myproject is the configuration name.

$ vfs-rsync-upload setup /path/to/mount dist myproject "--exclude /piwik --exclude /blog"

This creates some files and directories:

  • a .p12g file in the current directory, containing a configuration key, which is appended to your configuration name to prevent name collisions.
  • a .p12g directory in your home ("p12g" for "publishing") and
  • a myproject-configKey directory in the .p12g dir, with the structure outlined below:
    • remotes
      • production (symlink to /path/to/mount)
      • qa (symlink to /path/to/mount/qa)
      • staging (symlink to /path/to/mount/staging)
    • mirror
      • production (dir)
      • qa (dir)
      • staging (dir)
    • batch
      • production (dir)
      • qa (dir)
      • staging (dir)
    • sync_dir (symlink to dist)

Afterwards it synchronizes the folders in remote with the folders in mirrors, using rsync, appending the contents of the fifth argument to the defaults arguments (i.e.--write-batch=batch), but note that this will not synchronize the contents of the current directory. Maybe I'll add that later.

Upload files

$ vfs-rsync-upload staging

This uploads the contents of dist, as you set up above. As first this will rsync the local mirror (mirrors/staging) and the directory (dist) and write a batch (batch/staging/batch and batch/staging/batch.sh). Afterwards it calls the batch.sh and uploads the changes to your remote directory. Currently only staging, qa and production are supported. In future you should be able to define your own "targets" too.

Links

SFTP upload speed isn't the best you can imagine, but I "found" a "trick" to improve this.

Let's assume we have a project folder with dist containing the files you want to upload, troet as SFTP user, example.com as address and public_html/foo/bar/proj as target folder.
The "trick" I found is rsync's batch mode --write-batch=name.

BATCH MODE

Batch mode can be used to apply the same set of updates to many identi-
cal systems. Suppose one has a tree which is replicated on a number of
hosts. Now suppose some changes have been made to this source tree and
those changes need to be propagated to the other hosts. In order to do
this using batch mode, rsync is run with the write-batch option to
apply the changes made to the source tree to one of the destination
trees. The write-batch option causes the rsync client to store in a
"batch file" all the information needed to repeat this operation
against other, identical destination trees.

[...]

-- rsync(1)

First run rsync against any local directory, e.g. mirr. With batch mode, rsync writes a batch file containing all the changes made. It also generates a handy script you can use to apply that to any other directory. Use that to apply it to your mounted SFTP directory (use SSHFS or GVS).

Tada!

$ cd proj
$ ls
dist
$ rsync --write-batch=mybatchname -ru dist/ mirr
$ ls
dist mirr mybatchname mybatchname.sh
$ mkdir target
$ sshfs troet@examle.com:public_html/foo/bar/proj target # Asks for password unless you installed sshkey :)
$ ./mybatchname.sh target

Maybe you stumbled into a similar error, I've searched my self to death but now found what's going on.

TL;DR

Setup

Let's assume you have an index.php in /home/pi/public_html/foo/ and RewriteRule ^(.*)$ index.php/$1 [L] in .htaccess (essentially). The content of the index.php is not relevant.

Now, if you visit http://raspberrypi/~pi/foo/rewrite/this/plz you always get:
404 /home/pi/public_html/foo/index.php/rewrite/this/plz not found.
Note that the 404 is about http://raspberrypi/home/pi/... not /home/pi... on your filesystem!

This is because of RewriteBase, if you set that to /~pi/foo it works, see serverfault.com: Apache2 mod_rewrite + userdir. Solution found!

Background

You may now interrupt and say: But it worked on my Debian Notebook? Yup. Same here.

My first thoughts where about a missing configuration, but a diff of the RaspberryPi and Debian config showed nothing (at least nothing regarding mod_rewrite or mod_userdir). I then searched the internet for HOURS. Nothing.

Then I thought that the version 2.4.10 vs. 2.4.23 could make a difference, maybe the packaging, the patches. But, no, not packaging or patches. I downloaded the sources of .10 and .23 and diffed that. Too much for me.
Then the most glorious idea of all came to my mind: CHANGES. Not caps because angry, but because there are CHANGES_x.y.z files. And: Win! There, in CHANGES_2.4.16 it is:

  *) mod_rewrite: Improve relative substitutions in per-directory/htaccess
     context for directories found by mod_userdir and mod_alias.  These no
     longer require RewriteBase to be specified. [Eric Covener]

Thank you, Eric, absolutely non-ironic, that's really useful :)

Also (highlighted by me):

The RewriteBase directive specifies the URL prefix to be used for per-directory (htaccess) RewriteRule directives that substitute a relative path.

This directive is required when you use a relative path in a substitution in per-directory (htaccess) context unless any of the following conditions are true:

  • The original request, and the substitution, are underneath the DocumentRoot (as opposed to reachable by other means, such as Alias).
  • The filesystem path to the directory containing the RewriteRule, suffixed by the relative substitution is also valid as a URL path on the server (this is rare).
  • In Apache HTTP Server 2.4.16 and later, this directive may be omitted when the request is mapped via Alias or mod_userdir.

-- mod_rewrite - Apache

RTFM!


TL;DR

RewriteBase /~pi/foo, for the why read the article :P

studienplan5.rb

Ruby. Nokogiri.

Wie ich einen iCal-Parser für unseren Studienplan schrieb. 499 Zeilen purer Code, 897 alles in allem.

https://github.com/criztovyl/studienplan5

da_gallery_dl

Ruby. Typhoeus. Nokogiri.

Wie ich einen Bulk-Downloader für DevianArt schrieb. 168 Zeilen Code.

https://gist.github.com/criztovyl/10ceed8600628dfb017aec353d196c52

Beide Projekte habe ich in vim geschrieben.

Stay tuned,

criztovyl, II.
@criztovyl

Help! GNOME stopped grouping my open windows!
- criztovyl, II., 2016

TL;DR at end of page.
You must have disabled the Alternatetab shell extension but you wouldn't be here if you havn't already disabled it: It's task is to stop window grouping.

Symptoms

If you press Alt-Tab your open windows aren't grouped while they're still grouped when using Super-Alt. (The Super-key is also known as the Meta-key or the Windows-key.)

If you have the same problem I had, check your dconf, there should be Tab in /org/gnome/desktop/wm/keybindings/switch-windows.

This is what causes the problem because there shouldn't be anything. If you looked attentive you may found out that the default value here is empty. Couldn't imagine any solution, can't you? :D

Don't know what's dconf? Not soo important, the only thing you should do is to check the key within your dconf editor. Launch it by searching "dconf" in your overview or by pressing Alt-F2 and entering dconf-editor. Then follow the path mentioned above in the left-hand tree :)
You also could use the dconf command.
Anyway:

Now bring grouping back!

Reset the dconf value of "/org/gnome/desktop/wm/keybindings/switch-windows" to "" (None), below the simplest way.

$ dconf reset /org/gnome/desktop/wm/keybindings/switch-windows

 

Happy Alt-Tab-ing :)

Further information*

dconf - Alternatetab shell extension - GNOME tweak tool

TL;DR

  • Alt-Tab does not group windows
  • Alternatetab extensions is disabled
  • Super-Tab works as expected
  • Solution: execute dconf reset /org/gnome/desktop/wm/keybindings/switch-windows in terminal
    or reset dconf "/org/gnome/desktop/wm/keybindings/switch-windows" to "" (None) manually.

* informations... still chuckling.
Windows is a trademark of Microsoft.