Cherrymusic is a music streaming server written in python.
We assume the deployment is done in /home/user/music.domain.com
1. Go to the deployment folder and clone the cherrymusic repo
git clone https://github.com/devsnd/cherrymusic
2. Create and enable the virtualenv
python3 -m venv music_env
3. Test if the cherrymusic server starts and stop it afterwords
python cherrymusic --setup --port 8080
4. If you executed this commands under another user than the one under which you want to run cherrymusic
(eg: you ran the commands as root but you want to run under the user `user`)
mkdir -p /home/user/.config/cherrymusic
cp ~/.config/cherrymusic/cherrymusic.conf /home/user/.config/cherrymusic/
5. Edit cherrymusic.conf from the `user`’s home and set the `basedir` with the path where your music collection is stored.
Today I updated google-chrome-stable to version 43.0.2357.124-1 and I had an unpleasant surprise. Everything was looking bigger: the top bar, the bookmark bar, the menus, the font on the website. Something like this:
It seems the fix is to start the chrome browser with –force-device-scale-factor option.
And the result is:
The UI looks again like before.
Today I played a little with Cassandra on Amazon EC2. It was a very user friendly and pleasant experience to deploy a cluster with 2 nodes in one region using DataStax OpsCenter.
First I started a m1.small instance in Amazon EC2 where I installed OpsCenter. For this I chose Centos 6, the official AMI. Before starting to install OpsCenter, we need to configure the firewall in order to be able to access it. In AWS console, under the Security group, there is “CentOS 6 -x86_64- – with Updates-6 – 2014-09-29-AutogenByAWSMP-“. We need to righ-click on it and Edit inbound rules. Here we add a new Custom TCP Rule with port 8888 and the Source IP: My IP.
Anyway, I noticed that the instance has also an iptables firewall and the port 8888 is not open. So, on the instance I did:
iptables -I INPUT 4 -p tcp --dport 8888 -j ACCEPT
iptables-save | tee /etc/sysconfig/iptables
Now, we can install OpsCenter. All you need to do is to follow the installation guide for RPM package from DataStax:
Recently I bought an SSL certificate for this blog from MegaSSLStore. My website is hosted on a FreeBSD machine and served by Nginx web server. In order to install the certificate on this machine, I downloaded from MegaSSLStore the certificate and CSR+private key and I copied them on my server in /usr/local/etc/nginx/ssl
# scp -P22 * firstname.lastname@example.org:/usr/local/etc/nginx/ssl
root@RTU001 /usr/local/etc/nginx/ssl # ls -lh
-r-------- 1 root wheel 5.5K Dec 14 11:39 razvantudorica.com.ca-bundle
-r-------- 1 root wheel 1.9K Dec 14 11:39 razvantudorica.com.crt
-r-------- 1 root wheel 1.1K Dec 14 11:39 razvantudorica.com.csr
-r-------- 1 root wheel 1.7K Dec 14 11:39 razvantudorica.com.key
Because I have an .crt certificate and also a ca-bundle I need to combine these two files in one certificate:
cat razvantudorica.com.crt razvantudorica.com.ca-bundle > razvantudorica.com-bundle.crt
After this, I changed the nginx website configuration file, in order to redirect all the traffic that is coming on http (port 80) on https (port 443).
Today I had to read about git tags in order to be able to explain in a better way why somebody would use tags and for what. The old (and still good) git workflow explains very well how to develop using branches but doesn’t explain too well why we create the tags and how should be used on production. It just saying “that commit on master must be tagged for easy future reference to this historical version”. If you followed that guide and now you are ready to go live with your code changes, you maybe wonder what should you do with the tag? Why did you create it. Some people would say, just leave it there, maybe somebody, in a shiny day will take a look to it. Just go to production and do git pull origin master. But I don’t think this is the purpose of the tag.