With more and more companies moving applications to the cloud, Google App Engine makes a lot of sense. GAE is a Platform as a Service (PaaS) product offered which runs on Google’s infrastructure. Some of the touted capabilities are seamless, limitless, and completely automated application scaling. In this article, you’ll learn how to setup a basic development environment for Google App Engine’s Python SDK on CentOS 6 using PyDev and Eclipse.
Joining CentOS 6 or Red Hat Enterprise Linux 6 to an Active Directory Domain is relatively simple. While Active Directory is proprietary software developed by Microsoft, it’s fairly ubiquitous in medium and large environments, thus integrating Linux and Windows services is very common in this day and age. DNS has to be working properly. You should be able to resolve mydomain.com using DNS.
First, we need to install winbind. This is the Samba service that integrates users, passwords, and other important functions with Active Directory.
yum install samba-winbind
That command should install any and all dependencies necessary. Another step is to install software necessary for initializing Kerberos tickets. While not strictly necessary to join the Domain initially (I believe), it makes troubleshooting a little easier.
yum install krb5-workstation
After those two packages are installed, you can run authconfig-tui to automatically setup pam and other important config files. See the screen shots below for example settings.
The above selections are appropriate. Use fingerprint reader is not needed unless your workstation has a fingerprint reader.
This stage is very important. Security model should be set to ADS. Domain should be the name of the domain without the top level domain. If your domain looks like my.domain.com, then you should put “MY” in this field. Domain controllers are the FQDN for each domain controller you wish your system to use. Unlike Windows, these are not automatically discovered by CentOS or RHEL 6. Separate each domain controller by a space. ADS REALM should be the full name of your Domain in ALL CAPS. Template shell can be whichever you choose. If you want to enable domain users the ability to log in by default, select one of the shells. If you want to disable ssh/local login by default, select /sbin/nologin.
Next, select Join Domain and enter your Domain Admin username and password in the boxes provided. You should enter just the username, do not enter any domain information here.
For years, Linux administrators have been successfully using Samba winbind to integrate Linux with Active directory. While configuring a Linux host to join an Active Directory Domain is pretty simple, it still involves editing a few configuration files manually in most cases. The new software, realmd, changes all of that, and makes joining a Linux host to an Active Directory Domain easier than ever before!
Extremely awesome SQL query I wrote.
use my_db INSERT INTO dbo.my_archive select ltrim(rtrim(str(b.my_id)))+ltrim(rtrim(str(b.date))) pid_date, b.my_id, b.date, p.column1+p.column2 ssdd, p.last_name, p.first_name, COUNT (*) Amount, ( select COUNT(*) from amounts b1 where b1.flags = '1' and b1.my_id = b.my_id and b1.date = b.date ) Deleted, ( select SUM(m.count1) from mail_counts m where m.my_id = b.my_id and m.date = b.date ) Counts from amounts b inner join pusers p on b.my_id = p.my_id where (b.date < '20130701' and b.date >= '20120101') and not exists ( select * FROM dbo.my_archive mt where mt.pid_date = ltrim(rtrim(str(b.my_id)))+ltrim(rtrim(str(b.date))) ) and p.column1 != 'TS' group by b.date, b.my_id, p.first_name, p.last_name, p.column1+p.column2
Here are some tools I use on a fairly frequent basis, which may or may not be installed by default in your distribution. I highly recommend installing these tools during the provisioning stage of your system/environment because repositories aren’t always reachable on production systems. Furthermore, installing software on a running critical production system is often a tightly controlled process.
Part one, take the first full backup. At the present time, this code is still under development and should not be used on a production machine. However, I am posting it here for reference.
Eventually, this code is going to be included in a backup client I am developing that will interface with glusterfs and Amazon S3 storage.
Currently, this code is tested to run on Python v2.7.4 on a Fedora 18 machine. With all three python files, and any number of properly defined job xml files in the jobs.d/ directory, these scripts are currently functional.
Today, we’re going to be covering the 3 most important rules for any Linux System Administrator: Backups, Backups, Backups.
That’s right, if you don’t have backups, you have failed in your duties. Every single thing else you may have done to secure your system cannot replace the need for backups. Systems get cracked, hard drives fail, CPUs fail, RAM fails, password are forgotten, files get rm’d by mistake, patches break systems.
This article is about creating a simple backup script to backup your MySQL databases to an offsite location, complete with cron jobs, and encryption.
I’m writing this article for primarily for Debain Squeeze users, but it should also apply for Ubuntu 12.04 LTS and other releases as well, as the steps will be pretty much the same.
After you have downloaded and installed Google Chrome, you’ll most likely want to get Java working as well. Follow this article, and you’ll be up and running in no time.
It is debatable as to what the ‘best’ editor is in Unix/Linux world. I’m not going to attempt to answer that here, as it’s very subjective and besides the point. What I will do is outline the top 5 reasons that you should use vi, or at least familiarize yourself with it’s commands and basic usage.
Commands are quick and intuitive. After you’ve acquainted yourself with the commands, the built in functionality covers just about any task you can complete with a mouse.
Color syntax highlighting. If your terminal supports color, integrated syntax highlighting makes reading and editing scripts a much easier proposition.
You never have to leave your terminal. Most servers and production systems are located in a cold room with funny lighting, somewhere far away. If you’re working from a non-free operating system (GASP!), there’s nothing more annoying than having to upload the same file several times while you’re trying to tweak a setting. If you posses vi skills, you’ve already made your changes, saved the new file, and restarted your application, all before your mouse can even find the locally saved file!
It’s a ubiquitous application. It’s available on just about any *nix machine you’re likely to find in production today. If you work on or in a mixed OS environment, then you know it’s not very often your tools are so portable. Learn vi, and you’re covered for just about any appliance you can ssh into!