Oli's questions

So I've got a server with a single IP and a lot of websites, all hosted under nginx. Here's a very simplified reduction of my actual setup:

server {
    listen 80;
    listen 443 ssl;
    server_name ssl.example.com;
    #...
}

server {
    listen 80;
    server_name nossl.example.com;
    #...
}

If I connect to ssl.example.com:443 everything works, as expected.
If I connect to nossl.example.com:443, it tries to serve the content of ssl.example.com:443.

I've made my peace with the why that happens (it's just how ssl+nginx best-matches a virtual server), I just need to stop it sending content from the wrong site.

Short of buying certificates for all my sites (or issuing my own), or pushing the SSL site off onto its own IP, what are my options here? Can nginx double-check the domain for every SSL request and make sure it matches that server_name?

When my mailserver sends mail here are the headers:

Received: from example.com (localhost [127.0.0.1])
    by example.com (Postfix) with ESMTP id EB14D48159
    for <[email protected]>; Thu, 26 Dec 2013 11:56:12 +0000 (GMT)

This usually really isn't an issue apart from one customer's Postini filter is being particularly violent and seems to class this as an illegal address. I could fight them but it seems like it would be easier to just send email from the legal IP, right..?

So I've been through practically every Postfix setting. I have already set the following variables to example.com: masquerade_domains, smtp_helo_name, myhostname, myorigin, and I've set smtp_bind_address to our external IP. I don't know what else I can change that might have an effect.

How can I change the address/IP to our external address/IP?

I'm using Ubuntu 12.04, Postfix 2.9.6. I have seen and tried (as noted above) answers like those on How to make Postfix use another IP address? and I don't have any bind addresses in my master.cf file (I think that was the old way of doing things?)

I've got a bunch of websites on a server, all hosted through nginx. One site has a certificate, the others do not. Here's an example of two sites, using (fairly accurate) representations of real configuration:

server {
    listen 80;
    server_name ssl.example.com;
    return 301 https://ssl.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name ssl.example.com;
}

server {
    listen 80;
    server_name nossl.example.com;
}

SSL works on ssl.example.com great. If I visit http://nossl.example.com, that works great, but if I try to visit https://nossl.example.com (note the SSL), I get ugly warnings about the certificate being for ssl.example.com.

By the sounds of it, because ssl.example.com is the only site listening on port 443, all requests are being sent to it, regardless of domain name.

Is there anything I can do to make sure a Nginx server directive only responds to domains it's responsible for?

I'm sure it's been asked before in different words but I run several Django sites via uwsgi (emporer mode) behind nginx. It's all a fairly standard configuration but I find that if I restart the central uwsgi process, nginx just bombs out 502s rather than waiting for the socket to become available.

I recognise that most of this is probably for a reason but people seeing 502 errors really stings me. It's certainly not something I want a client to see. So...

• Can I beg nginx to wait/retry backends? Or,
• Is there anything (other than the obvious) I can do to minimise commercial damage from uwsgi restarts?

I'm running uWSGI in emperor mode to host a bunch of Django sites based on their individual configs. These are supposed to update when it detects a change in the config file and this largely works when I just touch uwsgi.ini the relevant file.

But occasionally I'll mess something up in the Django site and the server won't load. Yeah, yeah, I should be testing better but that's not really the point. When this happens, uWSGI seems to mark the site as dead and stops trying to run it (seems to make sense). Even after I fix the underlying issue, no amount of touching will get that site's uWSGI process up and running. I have to reload the whole uWSGI server (knocking dozens of sites out at once for a few seconds).

Is there a way to force uWSGI to just reload one of its sites?

I'm not sure how best to ask this question. Over several years I've developed my way into a corner and need to figure some things out. I almost certainly haven't been following best practices up until now but there you go.

I make and host Django websites on my own Linux (Ubuntu) server. I manage their version control with Bazaar and upload over SSH+BZR. They all go into a parent directory imaginatively called /websites/. The production copies are just master BZR branches (not exports). I don't run any sort of FTP server, just SSH.

My workflow is I edit a local copy of a website, commit the change. Because they're all bound branches, the commit it pushed to the server automatically and that has a hook which then runs an update, which in turn decides whether or not the Django site needs to be reloaded. I've just scripted things so they work for me.

All the websites' files are owned by my user account oli. The websites currently all run under that account too.

Occasionally a client wants access to their sites that's fair enough but I'm not sure if I can do that under the current structure. I think things need to change in order to let me achieve the following things:

• I can create a new user account for a client so that they can log in and play with their sites (and only their) sites. I do trust my clients but my other clients shouldn't be put in a position where I force them to trust each other.

• I can still work on all the sites just as I would with my own account, ideally in one place but I'd survive if on the server they were split up based on users.

• If possible, force the users to go through BZR so they don't mess up the production branch with silly faff that can't easily be rolled back. You know how this works: if I give a client access and something "mysteriously" stops working, it's my fault regardless of what's happened. I need to be able to track what's happening but similarly clients do need to be able to make changes without my interaction (the gatekeeper VCS model wouldn't work for me).

So assuming I can do anything to change my current setup, what's the best way of doing this?

My current thoughts are:

• Installing a simple FTP (et al) server that runs as oli to preserve any permissions and try to coerce them into using BZR but otherwise needing to sync updates.

  If you think this is viable, is there a secure equivalent to FTP that the system sees as one user but similarly something that I can arbitrarily limit to certain directories (eg user client-a can only view a subset of the website directories).

• Shake it up completely, use distinct SSH logins, keep websites in clients' $HOME dirs. If that gets your vote, what's my best tactic for stopping them doing anything but accessing their files? Is there a nice combination to limit ForceCommand internal-sftp with a chroot mechanism?

But I've learnt bad habits from hacking things around. How would you do this?

Possible Duplicate:
I can't send email from my server to gmail addresses

I have a VPS server that I host some domains on for myself and clients. A client wants a catch-all on a domain that gets forwarded to an existing Gmail account.

"Simple", I say and go through a quick tutorial on it. For testing I forward @original-domain.com to [email protected] (of course these aren't real - but the proper values are correct).

Now to test it. First I wrote an email to [email protected] using Mutt on the server. Two seconds later an email plops into my [email protected] inbox (which is actually a Gmail for domains account).

But for a real test I sent an email from [email protected] to [email protected], expecting to just email myself. Nothing came through. I can't find anything in spam or imagine any way that a filter could have caught it. I've looked everywhere for it.

I then decided to check on the server. In /var/log/mail.log there is a beautiful section:

Oct  3 12:59:40 nj postfix/qmgr[26568]: 9AFE448161: from=<[email protected]>, size=1063, nrcpt=1 (queue active)
Oct  3 12:59:41 nj postfix/smtp[26575]: 9AFE448161: to=<[email protected]>, orig_to=<[email protected]>, relay=ASPMX.L.GOOGLE.com[209.85.143.26]:25, delay=1.1, delays=0.29/0.01/0.
11/0.67, dsn=2.0.0, status=sent (250 2.0.0 OK 1317642647 et3si10294675wbb.52)
Oct  3 12:59:41 nj postfix/qmgr[26568]: 9AFE448161: removed
Oct  3 13:00:10 nj postfix/smtpd[26569]: disconnect from mail-yx0-f177.google.com[209.85.213.177]

That looks good. I've had a look at the part where Mutt sent its message, and it's like-for-like.

Because it's connecting, that suggests the firewall is okay (and I explicitly allow p25).

Is the email getting rejected by Google? Wouldn't it change the status of the send message (above) to something other than OK? What can I test next?

I have a LEMP stack. Nginx sitting in front of PHP-FPM. Because some of the sites are heavy and there's OPCode caching, PHP is set up so that there are only 5 child processes running. The aim being that each child can deal with any request in less than half-a-second and then move onto the next request.

One problem I've found is that if it's a big chunk of HTML that's getting sent out, and the user has a slow connection, that PHP thread stays occupied until they've finished downloading.

Because of my current setup, I have a pretty unforgiving timeout inside PHP where the script is killed after 20 seconds. This is to make sure everybody gets a turn but on a slow connection, this can mean the user gets cut off with a 504 Gateway timeout.

I was wondering if there was some sort of buffer solution that I could implement within or just behind Nginx that sent the request through and then... well... buffered the content into its own cache and feed that onto the client as and when they could download it. The aim being that the underlying PHP thread can be freed up.

What I'm asking for doesn't have to be PHP-specific. Anything that deals with FastCGI, or even any Nginx-upstream might have a similar issue to this.

I host a few Django sites on one of my Ubuntu servers. Up until recently I've been using the Cherokee HTTPd which has the option to launch back-end applications like Django sites but I've just switched out to nginx.

Under cherokee, I just "run" Django sites (sites are stored in /web/):

cd /web/mywebsite/; python manage.py runfcgi workdir=/web/mywebsite method=threaded socket=/web/mywebsite/sock pidfile=/web/mywebsite/pid maxspare=3 maxrequests=500

And then I'd connect to the socket at /web/mywebsite/sock. Cherokee also runs this as a user of my choice, in my case www-data.

This approach has worked well for me under Cherokee but now I'm moving to nginx, I don't have something there holding my hand for process management.

Looking around, there are literally hundreds of different ways of managing this. Init scripts, cron checks, daemontools. But as I'm on Ubuntu (and probably always will be) Upstart seems to make sense... But where do I start?

Could somebody give me an example of a upstart script that runs the above and will respawn it if it dies?

I have several django sites sitting in /web/ (and they're the only directories in that directory) so if there's a cheaty way that I can get this one upstart script to launch them all (with the same settings) and monitor them, that would be super-extra-awesome.

I manage a server for a client who has several Wordpress blogs. They all precariously balance on PHP/FastCGI/nginx and it all works at the moment, just using a little more RAM than I'd normally be comfortable with.

Since setting this all up, Wordpress 3 came out and (with a plugin to maintain domain mapping) allows me to import all the blogs into one central blog. So I know I can achieve a desirable operating outcome... I'm just not sure if I want to sink hours into doing it.

The client now wants to add a couple more blogs to the server. We're clearly at a crossroads where it would make sense to act now if I'm going to go down the multisite road.

I don't really care about the clear administrative benefits rather the performance and the amount of free RAM.

Do you think I would be correct in assuming one codebase in RAM would cost less than having half-a-dozen single sites? Are there any other performance pros (or cons) that I'm missing?

Background: I maintain a server for a client who has half a dozen Wordpress sites on. They all have the W3 Total Cache plugin installed and eAcellerator is installed (might be APC).

All the PHP sites run through a single batch of fastcgi php-cgi processes (it's actually php-fpm but I'm not sure if that makes a difference) and that feeds into nginx.

Problem: php-cgi's CPU usage is quite high. Not terminally high but high enough to raise an eyebrow. The client wants to add more sites in the future and I want to avoid becoming CPU limited if I can help it.

Question: Is there any way I can find the scripts or even just requests that are causing the high CPU. I realise I might not be able to do anything with the results but it would give me a chance.

I've got a RAID1 array. I'm buying 4 more disks of equal size (they're the same model drives) and I'm trying to enumerate my options for a safe upgrade. Ideally they'll be one large ext3 volume.

Firstly, am I crazy? Do I really want to move software RAID1 to 5 or 6? Will I wish I never had? The machine is fairly powerful (an i7 with 12gigs of RAM) but will performance be significantly worse? Is R6 worse than R5?

I should add that there is nothing "running" of this disk - it's purely storage for a small network.

Step two: How do I do it? If I'm going for RAID6, is it best to create a new 6-disk RAID6 array in a failed state (ie 2 drives missing), copy the data across from the RAID1, break the RAID1 and add those disks to the RAID6?

I'm really keen for any feedback from mdadm users.

I've just bought two 1.5TB disks with the aim of creating a 1.5TB RAID1 array.

In my infinite lack of wisdom (and a lack of space inside the computer - it already had 6 disks), I stuck one in, formatted it to EXT4 and proceeded to copy data all over it from drives that I'm subbing out.

Now I want to create a mdadm RAID1 array with its twin disk. I thought this was possible. Probably involving unmounting and dding the content across but I'm sure I saw this somewhere before...

But I can't find the tutorial I used the last time I was setting up mdadm so I'm scared. I don't want to nuke 800gigs of data.

I've got an Ubuntu server. I installed Samba to share files with Windows clients and it started off fine. I recently added some shares that are based on UnionFS and now the samba server will not start at boot and I have to launch it manually (/etc/init.d/samba start works without error)

It's annoying and it's going to cause problems when the server gets restarted when I'm not there. Can anybody suggest an idea why it's not booting and/or give me a way to make sure it does.

Edit: Just restarted. Here's the log for the boot-up.

[2009/05/15 10:04:21,  0] smbd/server.c:main(1260)
  smbd version 3.3.2 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2009
[2009/05/15 10:04:21,  0] printing/print_cups.c:cups_connect(103)
  Unable to connect to CUPS server localhost:631 - Connection refused
[2009/05/15 10:04:21,  0] printing/print_cups.c:cups_connect(103)
  Unable to connect to CUPS server localhost:631 - Connection refused
[2009/05/15 10:04:21,  0] lib/interface.c:load_interfaces(546)
  WARNING: no network interfaces found
[2009/05/15 10:04:22,  0] smbd/server.c:open_sockets_smbd(554)
  open_sockets_smbd: No sockets available to bind to.

I realise I need to clean out some CUPS nonsense.. The "no network interfaces" part is really odd because it will start up (albeit manually).

Here's the log when I run /etc/init.d/samba start

[2009/05/15 10:09:03,  0] smbd/server.c:main(1260)
  smbd version 3.3.2 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2009

No grief about CUPS. No moaning about network interfaces. No nagging about sockets. How I like it.