Note on installing MailWizz

Mailwizz has a pretty convenient ‘one-command install’ available here. However I hit a snag when trying to run it

[cc lang=”bash”]
RUN schema.sql…
/root/mailwizz-install.sh: line 7: /var/www/mailwizz/html/apps/common/data/install-sql/schema.sql: Permission denied
[/cc]

The reason is SELinux doesn’t allow the docker daemon to read anything outside /usr/ directory. To give docker permission you need to use the z option. According to project Atomic:

If you want to volume mount content under /var, for example, into a container you need to set the labels on this content. In the docker run man page we mention this.

man docker-run
...
When  using  SELinux,  be  aware that the host has no knowledge of container SELinux policy. Therefore, in the above example, if SELinux policy  is enforced,  the /var/db directory is not  writable to the container. A "Permission Denied" message will occur and an avc: message in the host's syslog.

To  work  around  this, at time of writing this man page, the following command needs to be run in order for the  proper  SELinux  policy  type label to be attached to the host directory:

# chcon -Rt svirt_sandbox_file_t /var/db

This got easier recently since Docker finally merged a patch which will be showing up in docker-1.7 (We have been carrying the patch in docker-1.6 on RHEL, CentOS, and Fedora).

This patch adds support for z and Z as options on the volume mounts (-v).

For example:

  docker run -v /var/db:/var/db:z rhel7 /bin/sh

Will automatically do the chcon -Rt svirt_sandbox_file_t /var/db described in the man page.

Even better, you can use Z.

  docker run -v /var/db:/var/db:Z rhel7 /bin/sh

This will label the content inside the container with the exact MCS label that the container will run with, basically it runs chcon -Rt svirt_sandbox_file_t -l s0:c1,c2 /var/db where s0:c1,c2 differs for each container.

 

In essence, after you encounter the error above, navigate to the docker-compose.yml file and add ‘:z’ to the volumes, like this:


mailwizz-php:
build: .
dockerfile: php-fpm/Dockerfile
container_name: mailwizz-php
volumes:
- ./mailwizz:/var/www/mailwizz:z

...
mailwizz-webserver:
build: .
dockerfile: caddy/Dockerfile
container_name: mailwizz-webserver
volumes:
- ./mailwizz:/var/www/mailwizz:z
- ./caddy/Caddyfile:/etc/Caddyfile:z
- ./caddy/certs:/root/.caddy:z

Then, rebuild the images with

docker-compose up --build --force-recreate --remove-orphans -d

Finally, run the installation command

docker exec -it mailwizz-php /root/mailwizz-install.sh

And voilà! Your Mailwizz server is now up and running.

Temporarily ignore a file in git

To ignore a file
[cc]
git update-index –assume-unchanged file.to.ignore
[/cc]

To undo
[cc]
git update-index –no-assume-unchanged file.to.ignore
[/cc]
Alternatives: [cci lang]git stash[/cci], [cci lang].gitignore[/cci], but I need to keep the file in the working copy, and not touch the gitignore file since it’s synchronized for all developers

ssh-add tricks

 

From spike (https://stuff-things.net/2016/02/11/stupid-ssh-add-tricks/)

Listing

You can list the currently loaded keys with -l and -L. The former displays the keys’ fingerprints while the latter displays the entire public key. Both list the path of file the key came from, which it the only way I recognize them.

Deleting.

ssh-add -d file removes the key the file from the agent. ssh -D clears out all keys, taking you back to square one.

Locking

You can simply run ssh-add -D to remove all of your keys from the Agent, but then you have to go through the trouble of adding them back. However, if you just want to step away and make sure your keys are protect, you can use ssh-add -x:

1
2
3
4
% ssh-add -x
Enter lock password:
Again:
Agent locked.

The Agent still has your keys, but won’t allow them to be used until unlocked with ssh-add -X:

1
2
3
ssh-add -X
Enter lock password:
Agent unlocked.

Expiring

Instead of locking your keys, you can set an auto-expiry with -t after which the key will automatically be deleted from the agent:

1
2
3
4
ssh-add -t 60  ~/.ssh/random_rsa
Enter passphrase for /Users/spike/.ssh/random_rsa:
Identity added: /Users/spike/.ssh/random_rsa (/Users/spike/.ssh/random_rsa)
Lifetime set to 60 seconds

OS X Specific

On OS X ssh-add is integrated with the system keychain. If you give the -K option, as in ssh-add -K, when you add a key, that key’s password will be added to the keychain. As long as your keychain is unlocked, a key that has been stored in this way doesn’t require a password to be loaded into the agent.

All keys with their password stored in the keychain will automatically be loaded when you run ssh -A. This happens automatically on login.

I have mixed feeling about this feature, preloading your keys makes life easier, but it does remove a layer of security. If someone access your Mac, they get your keys. On the other hand, the probably get a lot of other things too. Typically, I take the lazy approach for everyday keys and keep the high-security ones out of the keychain.

When a password has been stored in keychain, ssh -K -d key-file both removes the key from the agent and removes it password from the keychain. Without -K, -d does not change the keychain and the key can be reloaded without a password. -D silently ignores -K.

There you have it, a pretty small but surprisingly helpful set of features, you now have in your bag of tricks.

Setup public key ssh login and troubleshooting

Short note on how to setup ssh to login without a password

Generate and copy key

ssh-keygen -t rsa

Copy key

ssh [email protected] mkdir -p .ssh
cat .ssh/id_rsa.pub | ssh [email protected] 'cat >> .ssh/authorized_keys'

Try logging in!

If that doesn’t work

Some host need proper permission and a second authorized_keys2

At the remote host

chmod 700 .ssh
cd .ssh
cp authorized_keys authorized_keys2
chmod 600 authorized_keys
chmod 600 authorized_keys2

SSH may settings may need to be modified

At the remote host

cd /etc/ssh
sudo vi sshd_config

Find the AuthorizedKeysFile line and uncomment it (or add it if it doesn’t exist)

AuthorizedKeysFile %h/.ssh/authorized_keys

Save file, restart sshd with

sudo service sshd restart

Further troubleshooting

Start a second instance of sshd on the remote machine, dump all output to console so you can diagnose

/usr/sbin/sshd -d -p 2222

On your machine, do

ssh -p 2222

Look for Authentication refused: in the logs, it should contains the reason your connection fails

Installing subversion support for Eclipse on Linux

You have two choice: subversive (Belongs to the Eclipse project) or subclipse (hosted on tigris.org).

Even though Subversive is the more ‘official’ option, I find it prohibitively confusing to install. You have to go to an external site (polarion) and download a bunch of stuff nobody told you what. It took me 2 hours fiddling back and forth between Eclipse site and Polarion site only to install the wrong stuff. Highly not recommended! Agrh!

I have a better start with subclipse. The only URL from their site worked perfectly with eclipse’s ‘install new software’ dialog. Better still, you don’t really need to install JavaHL (which is also ridiculously hard to install), you can use the SVNKit package in the same repository and everything will work.

To install subclipse, go here

 

For those of you who prefer JavaHL, here is how to install JavaHL on Fedora 16. JavaHL is another middle layer required between any Eclipse plugin and SVN (I don’t know why things are so complicated when it come to designing on Linux). Most of the sites on the internet recommends you to install that by

sudo apt-get install libsvn-java

But there is no such package on Fedora, so I tried to use add/remove software and searched for various part of the name. I finally found it when searching for ‘JavaHL’, the correct package name is

subversion-javahl

Documentation and tutorial and another thing the Linux community didn’t do well!