Tuesday, 20 October 2015

OwnCloud in Docker.


So today version 8.2 of OwnCloud is released (https://owncloud.org/blog/owncloud-server-8-2-comes-tomorrow-help-spread-the-word/). In this blog post we'll look at how you can deploy OwnCloud in Docker with persistent storage.

There really isn't an alternative quite like OwnCloud either. Think Dropbox, but on your infrastructure, think Google-like features without the data-mining.

So for this image we're going to use JChaney's build https://github.com/jchaney/owncloud

You're as usual going to need Docker installed, just head over to https://docker.com and you'll find an installation guide. In this particular example you're also going to need git installed too. We're going to clone jchaney's repository and build our images.

$ git clone https://github.com/jchaney/owncloud.git 
$ cd owncloud
 
Then we're going to edit the Dockerfile and change the OWNCLOUD_VERSION from 8.1.3 to 8.2.0
then we just build the owncloud image.  As usual, red indicates things you need to alter for specifically. The naming convention for images is username/imagename.

$ docker build -t alba13/owncloud820 .

I'd suggest altering the Makefile and changing the storage location, which is pointing to /tmp/owncloud (you'll lose your storage when you reboot if you leave it here) to a more useful location (maybe, /srv/docker/owncloud/) and also alter “image_owncloud ?= jchaney/owncloud” to “image_owncloud ?= alba13/owncloud820

$ make owncloud-https

The above command links to the self-signed certs on your host system, however you can edit the Makefile to point to specifically generated certs too. If you want to generate some simple self-signed certs this is a pretty simple guide http://www.akadia.com/services/ssh_test_certificate.html just remember to edit the Makefile and change /etc/ssl/certs/ssl-cert-snakeoil.pem and /etc/ssl/private/ssl-cert-snakeoil.key to names and locations of your certs.

Now the above command(s) will give you a simple OwnCloud deployment that uses SQLite3 for its DB. For most cases that maybe all you're looking for, but JChaney's image also gives you the ability to set up a MariaDB with persistent storage, and uses the --link option. Which basically means that the MariaDB is only accessible to Docker containers that you specifically link to. Don't think of it as a security control though, just think of it as keeping it all in the Docker family.

You can set this up with the following commands;

$ make owncloud-production
# and to find the DB's details to configure OwnCloud run this;
$ make owncloud-mariadb-get-pw
 
Then just visit https://127.0.0.1 and follow OwnCloud's install options.

Once you're set up and installed you can head over to the "Apps" section and add some more functionality to your OwnCloud install. There is an "Enable experimental apps" section, the name sort of suggests you should have a bit of caution.

So here you go, you're up and running with the latest OwnCloud, all wrapped up in a nice little Docker Container(s).

Enjoy

finux Xx

[note] In your make file you can edit the DOCKER_RUN_OPTIONS ?= --restart=always --env "TZ=Europe/Berlin" and change your Timezone. Also as you see above i've added the –restart=always option. This just means that the images will restart after a reboot or if they crash.

[note2] also, just in case you have any sync issues it might be worth adding "fastcgi_read_timeout 120;" to the nginx.conf file(s) with the other fastcgi perimeters.   (https://www.tekovic.com/fixing-timeout-between-nginx-and-php-fpm)

Monday, 19 October 2015

Docker, and Openfire!


In the past couple of posts ive discussed how you can use docker to deploy Gogs (which we then used as a password manager with Pass), then I blogged about how you can use it to roll out OpenVPN very easily, and I wrapped up how we can use Docker to deploy Bind to block ad-servers. They were pretty short posts, and that in some ways lends itself to how easy Docker is to do deployments. I've said it a lot of times that Docker is like a cross between, Git, apt-get, and Vbox. I'm going to continue this run with a few other blogs this week about other day-to-day services that people may find useful.

So lets start this week off with XMPP, or more to the point Openfire. With Openfire, you can have your own private XMPP server for chat. Openfire is a pretty easy to use server which is even easier to deploy using Docker. Within a few commands you will be able to have your own chat server which can communicate with the rest of the world, but under your control.

As usual you'll need to make sure you have Docker installed. If you don't have it installed then please either visit https://docker.com or use a search engine to find guide for your OS.

We're going to use the great work of Sameersbn again (https://github.com/sameersbn/docker-openfire), and i'd also suggest either using a Dynamic-DNS service like these people https://nsupdate.info/ (they offer instructions on how to update your sub-domain to your IP address, you'll need it later when you configure Openfire) or buy yourself a domain name, they're pretty cheap after.

So we're going to pull the openfire image down from the the docker hub, however feel free to build the image yourself ('$ docker build -t' ).

So here we go

$ docker run --name openfire -d --restart=always \
  --publish 9090:9090 --publish 5222:5222 --publish 7777:7777 \
  --volume /srv/docker/openfire:/var/lib/openfire \
sameersbn/openfire
 
and there you have it, you've just installed and deployed Openfire in a single command. Now all you need to do is configure it. Go to http://127.0.0.1:9090 and follow the install instructions. You'll find a folder on your host system at /srv/docker/openfire with the configuration details if you ever need access to them. Remember you'll need to set up port forwarding on your firewall/router to be able to communicate with the outside world. If you're looking for a client for your Android phone my I suggest grabbing Conversation (https://f-droid.org/repository/browse/?fdid=eu.siacs.conversations) it's pretty nice. Also its worth mentioning Openfire has plugins, you could use those plugins to install Kraken which will give you a Facebook and GTalk transport as well. Which the tl;dr of that is, you can have Facebook IM's and GTalk i'm all rolled in to a single account.

Hope some of you find interest in this post

Finux Xx

Friday, 16 October 2015

using docker to block ads


So i'll continue the Docker run of blogs with another short guide with how we can use docker to block ads. To be fair, this is yet again an example of using a container to do a relatively simple task an make it even easier. The idea here is we're going to containerize a Domain Name Server (DNS), in addition we'll run a script that will pull down ad-servers and block them. Then you just need to point your devices on your network to the DNS and boom, you've reclaimed some bandwidth and saved yourself being exposed to some rather crappy ads.

So yet again, make sure you have docker installed.

We're going to use the excellent work of Sameersbn's bind docker image (https://hub.docker.com/r/sameersbn/bind/). All though i'm going to modify it slightly, as always you can build it with the 'docker build -t' option, \0/ yay!

We're also going to run a container that serves a pixel on port 80. This will be served to whenever our client speaks to our DNS looking for one of the ad domains in a blocklist.

The first time you run the DNS container you'll need to supply it two environmental variables, DN4C (the domain name you want for the container) and IP4C (the IP address of host you're serving from). As usual red indicates specific to you settings. Its pretty simple to be honest, basically;

$ docker run -d -e DN4C=alba13.com -e IP4C=192.168.2.100 -p 53:53 -p 10000:10000 --name adbind -v /srv/docker/bind/:/data arr0n/docker-adbind 

$ docker run -d -p 80:80 --name pixlserv arr0n/docker-pixlserv

There is a script called dc-bind-ad-block.sh that's called with the entrypoint.sh script. This pulls down known ad-servers and when a client requests one of those domains from the blocklist, it will be served a pixel locally. Both images and scripts are available on the Docker-Hub but if you wish to build them yourself you can find them at https://github.com/arr0n/docker-adbind and https://github.com/arr0n/docker-pixlserv. Also the DNS container has webmin installed in case you need to do any administration to the server. You'll find a folder called 'data' in your working directory that stores all the configuration files. I'd also suggest running the containers with the --restart=always switch. Now all you'll need to do is point your client to the DNS container and ads will be blocked for you.

Enjoy

Finux Xx

[note] 


As I said the DNS image we're using is only slightly altered from Sameersbn, I've taken this paragraph from his Github. I obviously suggest you set the ROOT_PASSWORD variable too.

"When the container is started the Webmin service is also started and is accessible from the web browser at http://localhost:10000. Login to Webmin with the username root and password password. Specify --env ROOT_PASSWORD=secretpassword on the docker run command to set a password of your choosing."


Thursday, 15 October 2015

From zero to OpenVPN in.......

So i've talked about this for a little while, and i've decided that I will post another short little guide about it today. I think one of the things I like about Docker (yes, I said like, don't judge me!) is that you get an almost apt-like experience with some cool applications. A great example of this is deploying OpenVPN in next to no time at all.

So this is going to be short and sweet, i'm going to take for granted you have Docker installed on your box. If you don't then hop on to a search engine (why not try Bing, I hear great things about it) and look for a guide about installing Docker on your platform.

We're going to use the excellent work of kylemanna (https://github.com/kylemanna/docker-openvpn) the commands below will automatically pull down the image, but as usual feel free to clone and 'docker build' the image. Also, you're going to need a public facing IP address or domain. If you're planning on doing this at home, may I suggest running over to https://nsupdate.info/ for dynamic dns if you don't already have something. 

Red, indicates your input!

# lets get a data-only container spun up, this will also place a folder in your working directory called openvpn. 
$ docker run --name openvpn-data -v /srv/docker/openvpn:/etc/openvpn busybox

# lets get the config files and certificates set-up certificate 
$ docker run --volumes-from openvpn-data --rm kylemanna/openvpn ovpn_genconfig -u udp://VPN.SERVERNAME.COM
$ docker run --volumes-from openvpn-data --rm -it kylemanna/openvpn ovpn_initpki
 
# you'll be asked to set some passwords for your OpenVPN's certs.  Whatever you like is cool with me. 
 
# Let's get the OpenVPN up and running 
$ docker run --volumes-from openvpn-data -d -p 1194:1194/udp --cap-add=NET_ADMIN kylemanna/openvpn

So you've just deployed OpenVPN in a container, with persistent storage in 4 commands. I know right, it's kinda cool to suddenly be able to have a OpenVPN on any box you can run docker on without being a card carrying member of the sandal brigade. However we're not finished just yet. Lets generate some certificates for our end-users (this is probably you).  Remember that password stuff we did, you'll need the ca one.

# Generate some client config files, remember to change CLIENTNAME to the Name of your Client ;) 
$ docker run --volumes-from openvpn-data --rm -it kylemanna/openvpn easyrsa build-client-full CLIENTNAME nopass

# and lets retrieve the files
$ docker run --volumes-from openvpn-data --rm kylemanna/openvpn ovpn_getclient CLIENTNAME > CLIENTNAME.ovpn

You'll find a .ovpn file in your working directory which should work with most OpenVPN client implementations, however inside that openvpn folder you'll find your client certificate files if you need them. I'd suggest you does this for every device you want to connect to have connected to your OpenVPN container. What I mean is for CLIENTNAME you have PHONE and LAPTOP and OTHERLAPTOP, so on and so forth. Trust me, in the end, makes life easier for you.

That's it, you're up and running with OpenVPN. If you want to autostart your OpenVPN container, so when your box reboots it starts again look into the '--restart=always' switch ($ docker run --volumes-from openvpn-data -d -p 1194:1194/udp --cap-add=NET_ADMIN –restart=always kylemanna/openvpn)

Now for the very cool trick with this, Digital-Ocean. You basically can have OpenVPN in the 'cloud' for 7 cents a day. You can then destroy it once you're done, or have it as a OpenVPN deployment you use when you're out an about. That's your choice. Do me a solid though, if you've not signed for Digital-Ocean and want to try it signup with this link please (http://tiny.cc/finuxdo) its my referral link, and i'll get some credits on my DO account.

Also, go read the github page from Kylemanna.  Its full of useful information, and its an example of how people who maintain docker-images should document them https://github.com/kylemanna/docker-openvpn

Finux Xx 

Wednesday, 14 October 2015

Using docker as a password manager!



Alert, this is click-bait peeps. I'm not really using Docker as a password manager, i'm using a password manager ran inside of a docker container. 

In fact even that's not exactly true, i'm using Docker to run a Git server, and i'm using Pass (http://www.passwordstore.org/) to PGP encrypt password files. I thought I would write a quick little howto guide in case anyone was interested. 

With this particular solution you get a password sync solution that can be used easily on Linux and Andriod, I have no idea how well it runs on Apple or Windows, but i'm guessing you could use Docker to fix that for you too.

So why am I using Docker? Because the revolution will be containerized people! Or more importantly, because I can. Secondly, i've found running a git installation with in Docker to be really, really, easy. So, i've played with GitLab, and yes its very nice and shiny. However I really like Gogs (Go git services http://gogs.io/), its light weight, does everything we need and its also lightweight. I guess what I like the most about Gogs is how lightweight it is, however experience has taught me when something is lightweight it is also buggy. I'm glad to report Gogs doesn't break the axiom, which makes it ideal for running in a container. No seriously, ideal because its not going to hose everything because its in a container.

So lets start with the obvious, you must have docker installed. I hate that fact we're in a world where I have to say this, but then again we have to tell people not to use hair-driers in showers, so I guess I can't grumble. I'm not going to tell you how to install Docker, because there is nearly 6 million hits on Google and if you can't work that out, this guide is way beyond your pay-grade.

Once you have a working Docker installation we can pull Gogs down (you can build it via the Dockerfile too)

# Pull image from Docker Hub.
$ docker pull gogs/gogs

# Create local directory for volume.
$ sudo mkdir -p /srv/docker/gogs/

# Use `docker run` for the first time.
$ docker run --name=gogs -p 10022:22 -p 10080:3000 -v /srv/docker/gogs:/data gogs/gogs

# Use `docker start` if you have stopped it.
$ docker start gogs

zomg, zomg, zomg, you've just set up git server with persistent storage and it was less than 4 commands. Now here we go, go to your web browser and visit in 127.0.0.1:10080 and follow the install instructions.

Feel free to plug this into your MySQL deployment if you want (as far as I know, this image doesn't have MySQL installed, and it won't be persistent), but i'd suggest you just use the sqlite3 for now (yay, sqlite3 will be persistent as its stored in the /data folder).

I'd also suggest changing “Domain*” to the IP of the box you want to run this container from (i.e. 192.168.2.22 for example), also “Application URL*” (i.e. 192.168.2.22:10080, this will be handy later on). Also, for the love of god remember to change the SSH port too, to 10022.

Why not set up an admin account now, because nothing sucks more than not being an administrator from the get go.

Once that's complete you may get an error from your web browser as it points to (localhost:10080 instead of 192.168.2.22:10080 if this has happened, its because you didn't read the instruction above properly).

Now you're in Gogs (and logged in as your user) select “New Repository” fill in the details, you can name this repository anything you want, I don't care, its a blog post not a lifestyle choice.

Click “Create Repository”

Now click on the “Dashboard” tab again, and then the “Account Settings” button. Once there select SSH keys and add your SSH key there (if you don't know how to generate an SSH key I have no idea how you got this far, but I'm going to do you a solid and give you this link https://help.github.com/articles/generating-ssh-keys/).

Now for the fun part, you need some PGP keys. Now you could use the ones you already have, i'm not going to judge you for that, but hey why not generate specific keys for a specific job? If you're going to ignore that piece of advice then that's cool just ignore the next few steps (Just don't forget to install pass). In Ubuntu (or whatever Linux you're running) do the following;

$ sudo apt-get -y install -y pass gnupg #only in ubuntu 

Now you can run the code below in any Linux

$ gpg --gen-key 

The default option “1” is fine, but make sure the keysize is 4096 in the next option, and the final default option is fine too. Fill in the other options, however when you get to the passphrase option choose something strong!!!! I mean, this is going to be your master-password for your password-manager so lets no choose password123 or some other equally dumb password.

You'll need to move the mouse around a bit and maybe type whilst gpg is getting some entropy, this bit always sucks for me, it might suck for you too. Practice some patience, you'll get there.

Once that's done, you need to grab the key-id like this;

$ gpg --list-key

Then you need to initiate the key with pass show it knows which key to encrypt your passwords with

$ pass init D64AA6BE 
$ cd .password-store/
$ git init
$ git config --global user.email "your email address here" 
$ git config --global user.name "your username here"
$ touch README.md
$ git add README.md
$ git commit -m "first commit"
$ git remote add origin ssh://git@127.0.0.1:10022/finux/pass-for-alba13.git 
$ git push -u origin master
 
The stuff in the red is specific to you! Now lets generate a password with pass and push it to gogs-container

$ pass generate blogpost/test 24
$ pass git push -u origin master

You can view your password with the following command

$ pass show blogpost/test

I'd also suggest this;

$ man pass 

and then read the documentation.  If you're going to use a password manager it makes sense to read the documentation.

You'll be asked to enter your gpg password and boom, you'll have your password in front of you for copying and pasting. Superb, now a decentralized password manager. Which is cool, you can now sync your passwords on your all your Linux boxes. But that's not just it. You can also use the Android app too (there is an IOS app but I know nothing about it) (https://play.google.com/store/apps/details?id=com.zeapo.pwdstore) they're few GUI's as well, but you'll find out more info at http://www.passwordstore.org/

Side-note, you'll need to put your SSH key and Your GPG keys on your phone to sync/pull/push, don't be stupid and gmail them to your self. Get a USB cable and do it that way.

The documentation is pretty good, but it'll take you a little while to get used to it. I like this solution, its easy to run and deploy, and I don't have to trust anyone with my passwords.

This was suppose to be a fun little guide to get your up and running, nothing definitive. If this isn't the thing for you, then that's okay too. Have fun

Finux

[UPDATE] if you get this error message;

"Binary and template file version does not match, did you forget to recompile?"

Run this command

$ sudo rm -rf /srv/docker/gogs/templates