Ok, so this is a system for deploying an appliance type setup on your server possibly comprised of several packages?
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".
Thats not far from what we're aiming at with Juju. The idea is to encapsulate things so they're easy to mix and match and share between environments. Those scripts you saw were all islands unto themselves, and they had to be mapped onto your server. Juju puts them into "charms", which are just metadata+executables that encapsulate how to deploy a service, and how to talk to it.
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.
I'm not looking forward to setting up my first Linux mail server next week. Any tips for a fellow noob? There's so much information and so many guides out there I don't know where to begin.
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.
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.
Yes, if you can test it all out in a VM. Also keep frequent backups of your .conf files.
The main log file of interest will be /var/log/mail.log check that everytime you change something as many errors that are silent elsewhere will end up here.
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):
"Ok, so this is a system for deploying an appliance type setup on your server possibly comprised of several packages?"
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.
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.
A few questions maybe some of you already know. What's the "instance" that is spun up...an LXC container? Also, is this only for Server or will also be available on the desktop Ubuntu? Cloud only or is this also for local use?
Containers spun up depend on the provider, so if you deploy to Amazon it's going to spin up an AWS instance. However, if you're deploying to an Open Stack provider it all depends on the Open Stack configuration. Juju doesn't quite care what the provider does with regards to virtualization software.
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.
It's more service orchestration. So it's a collection of charms to deploy services in to the cloud. Heroku and Google App Engine are more PaaS Platform as a Service, Juju more designed to deploy to Cloud providers like Amazon, Open Stack, and bare metal.
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.
A package manager whose packages are all install scripts that depend on packages from explicitly-specified repositories for a lower-level package manager. Somehow I feel like this must have been tried already before -- maybe in the RPM side of the tracks, or zero-install, or klik?
This does more than just package installation, it operates at a higher level. A service may require several packages that need to be installed, configured, then configured to work with each other. All of that is captured in a charm giving you a way to easily deploy a service. So capture your start to finish setup for any service you use in a charm and you can no deploy, and scale that service, using Juju.
All of which is possible by creating a package for existing package managers. It's how I tend to manage services: I build packages that depend on the other packages I need, and that uses post-install hooks to orchestrate the connections between various services, or replaces config files.
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.
Sure, you can use dpkg to orchestrate connections between services on the same machine, but last I checked dpkg isn't aware of other machines running other services and orchestrating the connections between those. Service orchestration between machines is something Juju excels at. It's really server and service orchestration abstracted so that you don't have to worry about what machine is where and connected to who. Juju maintains those relations for you, so it's really more like apt for the cloud.
I have no idea whether their offering is any good or not, but I don't find your argument persuasive. The fact that someone else tried to do something similar does not mean that this can't work well, or that it shouldn't be done.
People once said that Apple shouldn't do a tablet because it had been done before and there wasn't a market for them.
And then some people just use no-nonsense packaging systems.
Like ArchLinux's pacman.
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)
I didn't get that till you mentioned it. Article talks about deploying to a cloud, but no details. I think the packaging of apt is great, but I don't understand how the cloud deployment fits in.
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.
Charms require different interfaces, so it depends on the charm. In this case mediawiki has two interfaces, a db (via MySQL) and a db-slave (for MySQL Slave configuration). When you add relations hooks fire on both charms, MySQL creates a username, password, database, and all other basic tasks to make a database work for an application, then passes that information to the mediawiki installation. From there Mediawiki charm db-relation hook fires to make sure Media wiki has all of this information in the right configuration files, install the basic MySQL structure for mediawiki, and several other tasks needed to make sure Mediawiki is installed.
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.
There are several blog posts about deploying with Juju, I think this was just an announcement about the Charm Store going live. There are some posts on http://cloud.ubuntu.com/tag/juju/ and examples at http://juju.ubuntu.com/
Seems like this a popular idea lately! People striving for simplicity can only be a good thing. Also check out https://github.com/j2labs/quickness (from the guy who made the equally interesting brubeck python framework).
Juju is written entirely in python (though a rewrite in Go is underway). In theory it will work fine on OS X, but there are a couple of challenges to making that happen:
* 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).
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