I've recently moved some of my "cloud" files to ownCloud. There are some files we all store in the cloud which we probably shouldn't: password files, financial information including taxes, and maybe some dirty laundry too. For these uses, you don't need "anywhere access", you probably just need convenient access between your own computers and the backups afforded by having the files stored both on your desktop and your laptop is probably enough.
OwnCloud is your own cloud and you install it on some station to be the file repository. A workstation, or an Ubuntu server, whatever you have. The stock package in Ubuntu 12.04 is the much older 3.0x. You can use this with the older sync clients, but it doesn't have file versioning and other features of the newer ownCloud versions. You can add the ownCloud software repository from their site. I assume that setting up ownCloud on Windows is a bunch of double-clicking, that seemed like too much effort so I didn't bother.
There isn't much configuration, once it's up your first hit to the web page does the configuration which includes: creating an administrator account, ... That's it. After logging in there are more options like requiring SSL if you want.
There are also a lot of plugins / apps for enabling calendar / contact sync, for integrating authentication with LDAP, external storage, and more than you can imagine.
Since you likely have a hard drive at least 500GB in size if not multiple TB, this is automatically a much larger repository than you'll get without a monthly bill from cloud services. It's pretty cheap too, a new drive should be under $0.10 / GB these days whereas DropBox is about that per month.
Like any of the cloud services, you can access files via web interface:
There is a "sync client" for PCs and that includes Windows, Mac, and the major GNU/Linux distributions (CentOS/RHEL, Fedora, openSUSE, Ubuntu, Debian). There are also mobile clients but I haven't tried them.
There's ownCloud for you. You can totally replace the big corporate run cloud services if you want or complement them.
For everyone who uses cron, you are familiar with the job schedule form:
min hr day-of-month month day-of-week <command>
A problem with cron job scheduling is if you want to schedule something, like backups or updates, for "the first Sunday of the month". The job spec "0 0 1-7 * Sun" will run every Sunday and every day on the 1st to the 7th of the month.
The way to work around this is schedule the job for the possible days to run and then as part of the command, check the date before running the command. I've just seen what is The Best format for this:
Up until now I used a slightly different form of this using the day of the week in the cron job and then testing date %d to test the day of the month. But the above form is far clearer and easier to schedule jobs with.
So props to kakapo for sharing that form and until cron changes how the day-of-the-month and the day-of-the-week fields are used, this will be the best way to schedule a job on the first Sunday of the month.
Nagios rules all and has great agents and plugins and also checks clusters. One of the things we have got recently at #dayjob is a generator for emergency power. Well, how do you know if the generator is running, is healthy, etc? Sure, there's routine checks that someone has to do, weekly, monthly, seasonally, etc but how do you know what's going on in real-time?
Like much machinery, generators don't always have a nice web-based monitoring system or even an SNMP interface - they have "dry contacts". Dry contacts, for those of you like me who think a voltmeter is something used by parking enforcement, is a simple electrical circuit which is either "open" and not passing current or "closed" and passing usually 5 volts. Usually it is something like a screw which you thread a sensor through.
Okay, so no IP interface. What do you use? Well, we're using these AKCP SensorProbe devices which come in a variety of shapes and sizes. For our generator we used the SensorProbe2DC to which you can connect two sensors supporting 5 dry contacts each. It's a little IP device you need to feed a data run and power to and then you screw in the leads from the sensor to the dry contacts on the generator - your installer can help with the latter.
The SensorProbe is a monitoring device so you can configure the alerts and view status from there. But the other thing is that it has an SNMP interface so you can now monitor your generator status from your regular network monitoring system, by which I mean of course Nagios. Good old check_snmp, tell it which OID is which, and you're off to the races!
So now we've got in Nagios a host (the sensorpobe) which has service checks telling us whether the transfer switch is on mains or generator power, if the generator is running, if the generator is set to "auto start", or having any other problems.
AKCP makes various other SensorProbe devices. The SensorProbe8 has 8 ports to which you can connect various sensors for temperature and humidity, airflow, water detectors, etc or single-port dry-contacts. If you look hard, you'll find also that your AC units and other equipment also have dry contacts. Avid readers who crack their equipment manuals will also find that dry contacts can also be used as output triggers not just receiving status. Once you have a lot of dry contacts, you can check out the SensorProbe8 x20 and x60 which come with a whole lot more dry contacts to check everything in your datacenter.
Autofs is great especially for NFS mounts between systems. Autofs will mount file systems on demand and then un-mount them again when they are not needed. This is especially a nice trick where servers are sharing NFS shares compared to putting the shares in fstab which mounts the file system on boot potentially putting you in a deadlock where server A is waiting on a share from server B and server B is waiting on a share from server A... A common issue for example is mounting /home from a shared location but then no other server can boot until the home file server is up and deadlocks are bad, um 'kay?
"yum install autofs" as needed, use your package manager of choice. Once you fire up the automount daemon, you can poke around in the configuration.
First thing you'll want to try with is in auto.master enabling the net (or nfs) -hosts line. This will create a multi-mount in /net where you can access shares via /net/<hostname>/<share path>.
That's really it. You can directly access files, for example in /net/homefs/data/home/username. Automount will automatically mount that share when it is accessed and remove it after it's been left idle.
What's it doing?
First, it will look up shares for you. When you do `ls /net/hostname`, it will return a list of shares available from the server "hostname". It's really that easy.
Any access to a share is automatically mounted. A shared folder, call it "work", will be mounted on the first user request for a file from that share. Whether that's someone using 'ls' or else writing a file to a specified path.
For convenience, my first tip is that you use symlinks to point to specific shares or locations. Rather than using the path "/net/workfs/export/work", do something like `ln -s /net/workfs/export/work $HOME/work`. Another example is for shared home directories, super common in UNIX environments. So link /home to /net/<server>/path/to/shared/home. It will bring up the shared home directories when a user tries to logon and will unmount the home share after the users are logged out.
This brings me to my next tip: the automatic timeout. Autofs will un-mount the share after an idle period. 10 minutes by default (depending on your platform). This may cause you some grief, for example if you have a job that runs every 10 minutes. You should adjust this timeout based on your needs (either up or down) but unless your running something on a schedule every 10 minutes, you probably won't have much of a problem with this default.
You can also tune your NFS settings in your auto.master config file. The defaults should work for most systems but if you do have to do NFS tuning, you can do this with autofs either for all NFS mounts or you can create specific mounts as needed.
The interesting thing with autofs is you don't have to use it just for network shares. You can use it for regular devices as well. One of the main things is that again, anything in automount will be mounted on demand and not at boot time. So if you have a large data volume, you can add it specifically to the auto.misc file instead of fstab.
From time to time autofs can get a bit mucked up. Usually when "you screw around too much". If stopping autofs and umounting any left-over shares doesn't work, remember "umount -f -l" which is force lazy unmount. Very useful. If the folders don't go away, like /net/server/path/to/share, try doing umount on them and then you can remove them (rm -Rf), just be careful. It depends whether rebooting is more risky than an rm -Rf.
Sometimes you want to send an email as HTML from a script or from script output anyhow. There's a couple ways to get the HTML page to the recipient. You can attach the HTML page or you can set your Content-Type to HTML. In my case, we're looking at scraping a web page as a cron job and sending it to some recipient(s) - the mainstay is:
curl 'http://server/web/page.html'
Attaching an HTML file is safe, but recipients may not like "opening attachments". For HTML email, the security risk is the same, but there's a perception that "opening attachments is bad" which I wouldn't discourage as a general practice. Rambling aside, "uuencode" will encode an attachment, any attachment, and can be used in general (word doc, zip file, etc).
curl 'http://server/web/page.html' | uuencode attachmentname.html The other way is to set the content type to HTML and the HTML becomes the body of the email. On some operating systems, namely Debian and Ubuntu, the mail / mailx command can add a header with the -a switch. This is pretty simple. curl 'http://server/web/page.html' | mail -a "Content-Type: text/html" -s "An HTML email" some-recipient@example.com However if you are on a Red Hat / Fedora / CentOS system, your mail command does not support the -a switch. Here you can use mutt and the mutt method will work in general. curl 'http://server/web/page.html' | mutt -e "my_hdr Content-Type:text/html" -e "set charset=\"utf-8\"" -s "An HTML email" some-recipient@example.com
There you have it. Personally not a fan of HTML email (since it opens the doors to a lot of malware attacks), but if you've got to generate HTML email, using standard tools instead of writing your own perl script to wrap the scraping of a web page and generating an email is going to be much simpler.
I've just been in a situation where there was a particular user whom we wanted to give some access to but needed to limit their general access which in Windows 7 and Windows Server 2008 R2 you can do with "AppLocker" in a very clear way. AppLocker sets rules that look much like firewall rules allowing or denying access to run different programs and this can be controlled either locally or through Group Policy Objects.
For example, you have a consultant helping you with your new ERP system (just saying). They need to launch the ERP application but you really don't want them firing up a browser or the RDP client and checking things out on your network.
Getting started with AppLocker is pretty simple:
Launch the local group policy management tool
Enable auditing only initially for exe/dll control
Create the default rules to allow basic or general access (if applicable)
Then you want to create your specific allow / deny rules. The AppLocker rules are going to be a collection of rules saying if they are allow or deny rules, who they apply to, what type of matching they use (path, or publisher), and then actual match. So you might have a rule like
Allow
Consultants
Path
Program Files\ERP\bin\*
If the consultant only matches this one rule, they will be allowed to launch binaries in the ERP's installation path and will be blocked from anything else.
The first thing to do is set your rules in audit-only which creates event logs for all access that is controlled by AppLocker. You can test out your rules very easily this way as there will be two types of events to look for: "access granted" and "access granted BUT applocker rules will block this when set to enforcing". Once you are satisfied you are not going to can all access to your regular users and that you are locking down the consultant sufficiently, switch to enforcing and you're golden.
Or for another example, maybe you just want to block an out of date version of Acrobat Reader from running on your network. You can set a rule to deny "Acrobat" publisher's "Acrobat Reader" program from running "9.0 or older". Again, easy to test using "audit only" before setting enforcing.
Looks like a dummy apparmor or selinux maybe? Honestly, I never made too much progress selinux. I would figure out how to get something working then wouldn't use it for a while and forget out how to work with selinux and have to start all over again.
It's official - there's no more free Google Apps. Google started by limiting free GA accounts from 50 users to 10 and now to 0. "thenibble.org" was registered in the magical times of 50 free users on your domain and has been grand-fathered in but there will be no new free GA accounts. Domain aliases can still be added to existing accounts and other features, however I suspect it's only a matter of time before Google stops porting "Enterprise" features into the free service. Fingers crossed!
