Django modelformset is powerful!

I spent two days trying all kinds of non-sense trying to setup a form for entering the temperature profile steps. In the end, it turns out using modelformset is so easy! No need to setup extra form for each model. No need to keep tracking which form is initialized by which object.  Two lines take care of everything!

RecipeSet=modelformset_factory(Recipe,extra=7,max_num=8)
n=RecipeSet(queryset=Recipe.objects.all().order_by(‘step’))

Django rocks!

Advertisements

Don’t repeat yourself, unless with style.

Don’t repeat yourself (DRY)

Every distinct concept and/or piece of data should live in one, and only one, place. Redundancy is bad. Normalization is good.

The framework, within reason, should deduce as much as possible from as little as possible.

In most occasions, repeating is a waste of energy and resources. When we do need to repeat ourselves, we should repeat with style, like Pachelbel’s Canon.

WordPress multisite domain mapping and subdomain dashboard access

It seems to be a common problem that one cannot access the dashboard of the new sites after setting up a WordPress multisite network. My Googling showed at least 8 different problems and solutions. Here is what I met and my fix:

1) After you setup the standard multisite network, you should be able to create site1.main.com and site2.main.com, and be able to access their dashboard.

SiteAdmin->Tools->Domain Mapping

Fig.1 setup in single site

2) You can then setup the WordPress MU Domain Mapping plugin. This will enable you to map site2.main.com to site2.com. (You need to own site2.com and be able to setup the DNS record and/or virtual host mapping.) Here comes the problem I met: my site2.com is working correctly, but I can’t access the dashboard of the site2.com anymore. It enters a login-loop and never goes anywhere. The URL looks something like this :

site2.com/wp-login.php?redirect=http%3A%2F%2Fsite2.com%2Fwp-admin%2F&reauth=1

3) You can do two things here:

SuperAdmin->Settings->Domains

Fig.2 setup for network

  1. Disable the Domain Mapping on network level. Go to dashboard of site2.main.com (change it back if you already set it tosite2.com). Enable the Domain mapping plugin on this site rather than on the network. Then in the “site admin dashboard->tools->Domain Mapping” set the site2.com there (Fig. 1). You will have a site2.com WP site, and a site2.main.com/wp-admin backend.
  2. Enable the Domain Mapping on network level. Besides all the official plugin setup instructions, you also need to add your site2.com in the “super admin->settings->domains” (Fig. 2). You will have a site2.com WP site and a site2.com/wp-admin backend.

I hope this will save somebody some time.

Setup a wordpress multisite network on AWS EC2 (4)

Update 12/29/2012: I just came across Stephen White’s instruction: It walked through the setting up of FTP service itself on EC2 if you haven’t done that yet.  The valuable part I picked up is forbidding FTPuser to open a shell, and stopping WordPress continually asking for your FTP login details. But in the user permission setting part, he didn’t restrict the FTPuser within their home directory with chroot.

Another thing we need to take care of before going into multisite setup, is the user permission. Because the wordpress we just installed belongs to either root (my case, because I used sudo when unzip the file) or EC2-user, but we don’t want to use the root account for later on FTP handling.

My solution is to create a new user (wp_admin for example) and change the wordpress folder owner to it. To put some restriction, you can also chroot so that wp_admin are restricted within the www folder.

sudo groupadd FTPusr
sudo useradd -d /var/www -M -N -g FTPusr -s /sbin/nologin wp_admin
sudo passwd wp_admin
sudo chown -R wp_admin:FTPusr /var/www/wordpress

Add the following lines to the end of your sshd_config:

Match Group FTPusr 
ChrootDirectory /var/www
ForceCommand internal-sftp
AllowTCPForwarding no
X11Forwarding no

Restart the sshd service:

sudo service sshd restart

OR, you can chroot the user itself by using Match User wp_admin in the sshd_config.

IMPORTANT: the httpd service owner might not be able to create the wp_config.php for you now. So go through that setup before changing the owner of the wordpress folder, or you have to manually create the wp_config.php on the server.

After all these, you can now setup the FTP in your wordpress and enjoy playing with plug-ins, themes and etc.

To stop WordPress continually asking for your FTP login details every time you update a plugin or theme, edit the wp-config.php file: You need to add the following lines after the MySQL database settings:

/** FTP Settings */
define("FTP_HOST", "YOUR_ELASTIC_IP");
define("FTP_USER", "wp_admin");
define("FTP_PASS", "YOUR_PASSWORD");

For more details on chroot, here are some useful refs:
http://askubuntu.com/questions/134425/how-can-i-chroot-sftp-only-ssh-users-into-their-homes
http://serverfault.com/questions/392601/how-to-add-user-with-sftp-ftp-access-to-var-www-html-website-abc-folder-on-a

josircg:

To chroot an SFTP directory, you must

1) create an user and force root to be owner of it

cd /home
mkdir john
useradd -d /home/john -M -N -g users john
sudo chown root:root /home/john
sudo chmod 755 /home/john

2) Change the subsystem location on /etc/ssh/sshd_config:

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

and create a user section:

Match User john
ChrootDirectory /home/john
ForceCommand internal-sftp
AllowTCPForwarding no
X11Forwarding no

Oli♦:

All this pain is thanks to several security issues as detailed here. Basically the chroot directory has to be owned by root and can’t be any group-write access. Lovely. So you essentially need to turn your chroot into a holding cell and within that you can have your editable content.

sudo chown root /home/bob
sudo chmod go-w /home/bob
sudo mkdir /home/bob/writeable
sudo chown bob:sftponly /home/bob/writeable
sudo chmod ug+rwX /home/bob/writeable

And bam, you can log in and write in /writeable.

Setup a wordpress multisite network on AWS EC2 (3)

AWS RDS is awesome. But it doesn’t come with a database management tool. All the searching results pointed to this tutorial from Ben Kuhl.

A short summary: First setup your phpMyAdmin on EC2.

Then in the config.inc.php file, add the following line after the existing server setup or setup loop:

$cfg['Servers'][$i]['auth_type'] = 'HTTP';
    $cfg['Servers'][$i]['hide_db'] = '(mysql|information_schema|phpmyadmin)';
    /* Server parameters */
    $cfg['Servers'][$i]['host'] = 'xxxxx.l2kj35ncj3.us-east-1.rds.amazonaws.com';

PHPMyAdmin uses $cfg[‘Servers’][$i] so that it can support multiple servers on one installation.  Having more than 1 server will give you the option to select a server when you login.  After that last you’ll want to add the following code, but of course with your own Amazon RDS instance URL.

In my case, I don’t have a config.inc.php file, so I made a copy from the config.sample.inc.php, and here is what it looks like now:

/*
* Servers configuration
*/
$i = 0;

/*
* First server
*/
$i++;
/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = 'cookie';
/* Server parameters */
$cfg['Servers'][$i]['host'] = 'localhost';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
/* Select mysql if your server does not have mysqli */
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['AllowNoPassword'] = false;
/*
* AWS RDS server
*/
$i++;
$cfg['Servers'][$i]['auth_type'] = 'HTTP';
$cfg['Servers'][$i]['hide_db'] = '(mysql|information_schema|phpmyadmin)';
/* Server parameters */
$cfg['Servers'][$i]['host'] = 'xxx.rds.amazonaws.com';

Then… it works like a charm!

Salute to Ben Kuhl!

%d bloggers like this: