Why the Juju Charm Store Will Change the Way You Use Ubuntu Server
jorgecastro.org
jorgecastro.org
This would certainly be useful to me. Earlier this week I attempted to setup of a Linux mailserver from scratch using postfix,dovecot,spamassasin,clamav,sasl etc.
Wow, what a pain in the ass that was, trying to get all the pieces to talk to each other correctly and trying to think of possible security holes.
Most of the help online was either lengthy manuals that were pretty difficult to digest or somebody posting a tutorial basically saying "run these commands and paste this into your config".
Not really ideal.
What I really want to do is:
sudo apt-get install a-working-mail-server-with-sensible-defaults
Debain/Ubuntu have a tasksel for a mail server but I haven't tried it yet. (https://help.ubuntu.com/community/Tasksel) > sudo tasksel install mail-server
I plan on trying some other semi-automated installers like iRedMail (http://www.iredmail.org/) in a VM first.
It would be quite difficult to write a decent guide in a short space (also I have not quite got my setup correct yet), but make sure you RTFM before you start.
Depending on how many users you have, if you are using postfix it may be easier to just map the users mail accounts to unix accounts rather than use virtual mailhosts (these allow you to designate a single account to store mail which will be divided into seperate folders for different domains/accounts, so useful if you are running many domains/users as you don't have to update main.cnf and change unix settings for each account) .
here is a basic guide (assuming you are not using virtual mailhosts):
http://rimuhosting.com/support/settingupemail.jsp?mta=postfi...
and one on integrating spamassasin:
http://www.akadia.com/services/postfix_spamassassin.html
Of course make extra sure you are not running an open SMTP relay (best way to check for sure is with telnet)!
Also you can setup fail2ban to watch your mail server logs for failed logins and automatically update your firewall rules to keep them out.
Use Sendgrid, MailGun, or some other managed email provider and let them deal with the headaches of running mail servers. It's seriously not an industry you want to try and understand or deal with. Setup an account, pay the service usage fees, and know that you're saving yourself a lot of headaches.
All of these services now have good APIs, callback hooks, and statistics to help you track the behavior of your mail traffic without having to write your own parsing pipeline.
Trade money for time when appropriate. Believe me that the time involved to deploy, run, secure, and maintain a flexible and stable mail infrastructure really isn't worth the time better used building a good application.
Howto Forge has some good tutorials (http://www.howtoforge.com/howtos/email).
Its all a question of why you are doing it. If your aiming to learn, then I would recommend using a howto and installing different components. If your running a business... seriously look at just using Google Apps or some other similar system. If you need sending capability then SendGrid and such are suitable for low volume (sub multi-million messages / month).
The biggest problem you are going to face in running your own server is keeping the design up to date.... every year Spam detection methods change, and you need to keep on top of that. Thats what eventually made me pack it in and move my hosting to google. I'm a RHCE and administer and support mail server for a some quite large national brands. But I can't be bothered for my own domain.
If your are or are looking to be a systems guy then LEARN EMAIL (SMTP, POP, IMAP), its one of the core competencies. If your a dev you should know it, but outsourcing the running of it can make sense. Just don't be a fool and outsource it if its the core of your business. If your sending (or recieving) above a certain threshold its almost always cheaper to do it yourself.
http://flurdy.com/docs/postfix/index.html
I actually followed the guide (not just read it) and got a working mail server in a few hours.
The idea is to give people a way to express to one another best practices in a way where it can be used directly (so no need for a human to translate that wiki page into automation.. its done). Then it can be measured, refined, and shared.
For your use case, not really. Installing software on server is a job for configuration management (e.g. puppet, chef). What juju seems to be about is managing the relationships between services, or service orchestration.
http://askubuntu.com/questions/52840/differentiator-between-...
Canonical used Go to build the backend for the Juju Charm Store: https://plus.google.com/107994348420168435683/posts/fdMcwvCq...
Seriously, just the other day I had to install package A from source but first I had to install repo B to download it and install language X to install it as that was what the build script used. The guys who I manage are probably sick of me threatening to write something exactly like juju.
I'm going to investigate juju further but if juju can determine the path of least build dependencies that would also be great i.e. if there are two build scripts, one bash and the other language X, it chooses bash as you do not have language X installed.
It would also help if each project offered a link to a tar of their latest stable version so wget could be used instead of repo B.
I like using the systems tools first before installing other tools.
However, for development you can setup a "local" provider (http://askubuntu.com/questions/65359/how-do-i-configure-juju...) and deploy to your own machine using LXC. This makes development quick and affordable and makes it easy to test drive Juju without needing to use a cloud provider.
Like, it helps you set up a Heroku or Google App Engine Application ?
Also, can I use it in another distro/Ubuntu desktop ?
As for different distros Ubuntu is the only distro that Juju has been tested on, though Juju is all Python so it likely wouldn't take much to port and maintain Juju to other Linux distributions. As for the charms most all are reliant on apt-get so Charms for different distributions that used other package management software, then charms would need to be updated to use those instead.
People once said that Apple shouldn't do a tablet because it had been done before and there wasn't a market for them.
The level of support for cleanly handling things like replacing config files vary between package managers, but I've done this easily enough with both dpkg and rpm.
I bet you can write a PKGBUILD for, lets say, zookeeper, including the config you want faster than it takes to deploy juju (which will use the configs it wants)
We're not talking about installing packages on your computer, we're talking about deploying services on a cloud.
Instead of deploying a lamp server onto one machine you deploy the service you want to your datacenter. This can either be EC2, your openstack cloud, or local machines.
Let's say you want to deploy a scaleable mediawiki at work:
juju deploy haproxy
juju deploy mediawiki
juju deploy mysql
juju add-relation haproxy mediawiki
juju add-relation mysql mediawiki
And then you have a load balancer, a mediawiki instance, and a mysql instance. You point your DNS to the haproxy instance, and you're ready to go.2 months later your wiki becomes way popular. Since you're on the cloud you're totally elastic, so you can go "juju add-unit mediawiki" and you've got another mediawiki node load balancing. Or do "juju add-unit n=10 mediawiki" and have 10 nodes ready to go.
If you're on AWS, each of those deploys fires up an instance. Same on OpenStack. If you're on bare metal the Ubuntu orchestra server on your network will turn on machines and install/provision them to do the equivalent.
that is cool.
Like could I simply switch postgres for mysql in your example and have it work, or does mediawiki specifically need a relation to a mysql?
On the flip side, adding a relation to haproxy, additional hooks fire in each charm. Mediawiki tells haproxy the address and port it's running on and haproxy hooks take care to ensure it's in the loadbalancer configuration.
What's excellent about these relationships is as you scale mediawiki to meet demand (juju add-unit mediawiki) all of this relation data stays in tact. So each additional unit will automatically fire the proper db hooks and loadbalancer hooks making sure every unit is setup exactly like the previous (in the case of MySQL, they'll be sharing the same MySQL database but it will skip re-installing the db for every unit) and HAProxy will loadbalance between each unit.
Same happens when you juju remote-unit mediawiki all the relavent hooks fire and each unit is removed from HAProxy.
* Juju is python, but links to the python zookeeper bindings which are C, so one needs something like homebrew to install Zookeeper. * Juju does sometimes make assumptions about Ubuntu specific stuff. We need some brave OS X users to try it out start reporting bugs so we can find out where these are and build tests around it (A good start would be if somebody wanted to donate an OS X machine to run the test suite on).
Any help in this area would be much appreciated!