orokusaki's questions

Package manager Homebrew (I'm on OS X, but I'm curious about Unix-based security in general, as it pertains to directory permissions) set the owner of /usr/local/bin to my user (it's root by default, right?), which means that now I can install executables by simply moving them to /usr/local/bin (no sudo required).

1. Am I right about this, that normally /usr/local/bin is owned by root?
2. Isn't chowning /usr/local/bin with your normal user a huge security issue, because now any software that I run can install programs on my behalf without my password being required?

I'm seeing a lot of the following line in /var/log/syslog:

Jun 21 14:36:15 my-server kernel: [416219.080061] iptables denied: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:the-mac-address:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=10081 PROTO=UDP SPT=68 DPT=67 LEN=308 

This seems to happen just about every minute. Is this just my server trying to broadcast something and my own iptables denying it from happening? If so, what kind of service might do such a thing, and should I allow it? I'm running Postgres 9.2.4 on Ubuntu 12.04.2, and basically no other services aside from the basic, pre-installed packages.

Note, I can't use SSL termination at the load balancer, due to network security related issues.

The client IP I get is of course that of the load balancer. I know that the load balancer can't modify the HTTPS message without having my key, but is there another way to get the client IP address when load balancing with SSL, such as maybe just load balancing at the TCP level, or something?

I often log into my Ubuntu 12.04.2 server (with Postgres 9.2.4 running with live production data) and see something akin to:

4 packages can be updated.
4 updates are security updates.

This happens about every few days, of course. I'm not interested in automatic updates (the fewer things I can have changing when I'm asleep, the better), but I am interested in always keeping my server up to date, so my question is: When I see output such as that, is it always considered safe to run apt-get upgrade, or are there times when it can break things. I understand that patches are not always perfect (hence the quoted "always" in the title), but as a general rule, is it assumed safe to run this (esp given this is a database server vs something that just serves CSS files via Nginx)?

I'm looking to redirect from HTTP to HTTPS. My Nginx server sits behind a load balancer which will terminate SSL for me and send all traffic (HTTP and HTTPS) to port 80. The only evidence I will have to indicate whether the original request made was HTTP or HTTPS is via the X-Forwarded-For header that is set by the load balancer. Is there a built-in, inexpensive way to handle redirection in Nginx when the original request was on HTTP? Keep in mind, I'll only have a server set up for port 80.

An iptables rule on my database server is:

-A INPUT -p tcp --dport 6432 -s 10.115.0.150 -j ACCEPT

I have other rules (loopback, etc.), but I'm wondering if that specific rule can be "hacked". Can somebody just "spoof" the IP address (even though it's a private network address - also, would it be different if it was a public address)? Something different?

I've been wondering for the longest time if a sudo reboot with a running Postgres (namely, 9.2.4) server can (or definitely will) lead to data loss or other problems (e.g., inability to start again the server upon system boot). Or, does reboot send the proper signals to processes that allow them to properly be shut down (including, for instance, allowing transactions to complete, etc.).

I've got an Ubuntu 12.04.2 server and I want to install Postgres 9.2.4. If I wanted to build all dependencies, I couldn't use apt-get build-dep (at least without some finagling) because only 9.1 is available to apt-get install. This leaves me in a "I wonder which new dependencies have been added since 9.1" sort of pickle. So, I decided to check Postgres 9.1's dependencies anyway, so i did a dry run:

me@my-server:~$ sudo apt-get build-dep postgresql-9.1 --dry-run
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  bison comerr-dev debhelper dh-apparmor docbook docbook-dsssl docbook-xsl flex gettext html2text intltool-debian krb5-multidev libbison-dev libcroco3 libedit-dev libexpat1-dev libfl-dev libgettextpo0
  libgssrpc4 libkadm5clnt-mit8 libkadm5srv-mit8 libkdb5-6 libkrb5-dev libldap2-dev libncurses5-dev libosp5 libossp-uuid-dev libossp-uuid16 libostyle1c2 libpam0g-dev libperl-dev libperl5.14 libpython3.2
  libssl-dev libunistring0 libxml2-dev libxslt1-dev libxslt1.1 m4 openjade opensp po-debconf python-dev python2.7-dev python3 python3-dev python3-minimal python3.2 python3.2-dev python3.2-minimal
  sgml-data tcl8.5 tcl8.5-dev xsltproc
0 upgraded, 54 newly installed, 0 to remove and 0 not upgraded.

... rest omitted

This tells me there are quite a few dependencies that aren't currently installed. Because of this, I decided to check out a dry run of the actual install of Postgres 9.1:

me@my-server:~$ sudo apt-get install postgresql-9.1 --dry-run
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  libpq5 postgresql-client-9.1 postgresql-client-common postgresql-common ssl-cert
Suggested packages:
  oidentd ident-server locales-all postgresql-doc-9.1 openssl-blacklist
The following NEW packages will be installed:
  libpq5 postgresql-9.1 postgresql-client-9.1 postgresql-client-common postgresql-common ssl-cert
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.

... rest omitted

Now, my question is due to the fact that if I simply apt-get install libreadline6-dev libghc-zlib-dev (from a tutorial I read), I'm able to install Postgres 9.2.4 just fine. It seemed to run perfectly fine, and make check passed. So, is build-dep usually a good idea in cases like this, or does it typically install a lot more than one really needs?

I have 2 physical servers, each will contain 2 VMs; a VM with Postgres (9.2) running, and a VM running some Python software (which will connect to the Postgres server). I'm not tied to anything in terms of types of failover tools, etc. Is there a way to avoid having a split brain problem given that I only have 2 physical servers?

My current understanding is that when my master Postgres server (or the machine that it resides on) dies the slave database will resume the role of the master. If the master server was turned back on again, it will think it's still master... Is this problem handled by modern Postgres versions, or is it still a serious issue, and if so, why don't more people talk about it? It seems rare to find anything about it.

The following headers (from a static media response) don't lead to caching in Firefox. In Chrome they do.

HTTP/1.1 200 OK
Server: nginx
Date: Sat, 22 Dec 2012 21:20:39 GMT
Content-Type: application/x-javascript; charset=utf-8
Last-Modified: Fri, 21 Dec 2012 19:28:54 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: public, max-age=86400
Content-Encoding: gzip

My Nginx server for static content looks like this:

server {
    listen 80;
    server_name static.example.com;

    # Logs
    access_log /var/log/nginx/static.example.com.access.log;
    error_log /var/log/nginx/static.example.com.error.log;

    # Root
    location / {
        alias /var/www/app/deps/current/repo/src/example/static/;
        add_header Cache-Control "public, max-age=86400";
    }
}

I've also tried using expires 24h;, in place of add_header ..., without luck.

I've found numerous, similar complaints on the Internet, but no solutions, nor any ideas of why this is, other than one person's mention of how Firefox purposely strays from the specification for handling HTTP 1.1 Cache-Control headers.

Is there any way to get Firefox to cache my static media, via a header or multiple headers? I don't want 75% of my server's static media requests to come from 20% of my users, just because Firefox is busted.

Note, I'm using Firefox 17.0.1 with default settings, but with Firebug installed and open to the Net tab.

Update:

Using, instead:

expires 1d;
add_header Cache-Control public;

Causes the headers to include:

Expires: Wed, 26 Dec 2012 19:54:20 GMT
Cache-Control: max-age=604800, public

This also doesn't cause Firefox to cache the content.

I'm getting ready to start using PGBouncer, but I'm unsure of whether it should be used on my database server or on the app servers. If it's on the app servers, there will necessarily be multiple pools of connections, vs one central pool of connections for the app servers to share, but then the TCP connections have to be recreated for each new query instead of also being pooled, presumably. Which is the "proper" way to use a connection looker like PGBouncer, and are the points I make about each even valid?

Note:

For those who stumble into this question, see PgBouncer FAQ (the last question).

First, I ran:

sudo su postgres
createuser -U postgres foouser -P

which worked fine, and I ran:

createdb -U foouser -E utf8 -O foouser foodatabase -T template0

and got "permission denied: cannot create database"

Firstly, should I even su as postgres to do operations like the first one (assuming my postgres data dir is owned by postgres), or is -U postgres from any user (assuming trust is used in pg_hba.conf) sufficient?

Secondly, why am I running into this error? Is this because the user foouser is a non-superuser? Should I create foodatabase using the postgres user and simply -O foouser?

I'm using Supervisor and the uWSGI Emperor mode. When I set limit-as to 512 (MB), workers die instantly (respawn, die, respawn, die, every 3/4 of a second or so):

[uwsgi]
workers = 4
threads = 40
limit-as = 512
harakiri = 20
max-requests = 1600
... non-performance/memory/processor-related settings ommitted

But, if I change limit-as to:

[uwsgi]
workers = 4
threads = 40
limit-as = 1024
harakiri = 20
max-requests = 1600
... non-performance/memory/processor-related settings ommitted

and restart uwsgi, the problem is gone immediately. In order to put a sham in this, I've modified the setting back to 512, restarted again, and the problem is back immediately.

Notes: My app is a simple Django app without much additional Python setup during start-up time.

I have 1 physical machine with 2 VMs (VMWare esxi) - one for database (PostgreSQL 9.2.1), and one for application. I'd like my application to connect to my database in an efficient way, and I've heard that using a file system socket is more efficient than a network socket (TCP overhead, IIRC).

1. Is there a way to use a file system socket with the aforementioned setup? Or...
2. Is there another, efficient connection method you'd recommend?

I have a SaaS application wherein users can enter their domain names. The application uses the hostname of incoming requests to determine the account based on the domain they entered for their account, loading up settings, themes, etc.

I don't want to have to add a new Nginx host for each new domain that's added by a user, which leads me to a solution wherein I have all the people point their www CNAME to a static subdomain on my server (e.g. all-websites.[my domain].com), redirecting each root request to its respective www version (e.g. example.com redirects to www.example.com).

Will the aforementioned solution work, and if so, are there any drawbacks, and if not, do you know of a better solution which still doesn't require me to update Nginx configs every time a user signs up (I also don't want to have a script editing configs for me).

Note: I am using Apache2 (on Linux), but I asked in a general sense (for Linux only) because I'd also like to know the "best" way to do accomplish this in a general (since I'm about to deploy a large site on Nginx, or Cherokee).

My log files are becoming huge after just a few weeks. I need to keep them around temporarily, but I'd like to delete entries that are older than 2 weeks, or so. Is this possible, and how do I do it?

I promise I don't mean to cause a war here, but I want to ask why so many people recommend using "enterprise" Linux (specifically Redhat) over something like Ubuntu Lucid. Is this purely for support/warranty purposes, or could somebody give me a list of some key things that make Redhat more suitable (if there are some) (my purposes are for a hosted SAAS platform on the web).

I don't want anyone to be able to detect that I'm using NGINX or even Ubuntu from the internet. There are tools out there (such as BuiltWith) which scan servers to detect what tools they're using. Also, some cracking tools might help with deteting. What's the best / closest to that I can get to hiding all this info from the outside?

The reason I want to do this is because users develop against our API with JavaScript, and some developers screw up and cause visitors to slam the server with AJAX requests. When this happens, I want to be able to throttle the API requests to perhaps 50 requests per minute, or something to that effect.

Note: (particularly DB intensive resources, so perhaps at a path level, rather than server-wide (e.g. throttle "/json_api/", but not "/static/").

Let's say I have an application that allows clients to create an account and put a form on their site that allows people to create tickets. With 475 clients who have websites with forms. They get about 100 form submissions per day per account (47500 total tickets per day on average). If you assume that all of those take place during only 8 hours of the day, it comes to only 1.6 or so tickets per second.

If I was shopping for a load balancer, does this mean that I only need one that can handle 5 SSL TPS? This seems ridiculous to me?