The Mainline PPA has been updated to 1.5.9, which is the latest mainline release of nginx.
I apologize to the people who use the nginx PPAs, I’ve been a bit busy and have not had a chance to update the nginx PPAs until now.
The Stable PPA has been updated to 1.4.4-4, which is the latest package in Debian Unstable.
The Mainline PPA has been updated to 1.5.8, which is the latest mainline version as of this date. The Lua module in the nginx-extras package has been updated to the latest version of that third-party module, in order to resolve an FTBFS issue.
The NGINX PPA has been updated for all currently-buildable Ubuntu releases to 1.4.1-1 even though I said I’d stop upgrading Lucid, Natty, and Oneiric at 1.4.0. I only just got my hands on 1.4.1 (from Debian Unstable, because it was only available today), and updated the releases I could because of a nasty vulnerability in the software.
Also, some of you were asking about the SPDY support to me via email. SPDY support is only in the nginx-extras package.
The NGINX Stable PPA for Ubuntu has been updated to have the 1.4.0-2 packages from Debian Experimental, and will be modified when bugs get raised against it.
At the same time, however, there have been update restrictions placed on the PPA as of today:
The stable PPA is no longer updated past 1.2.x for the following Ubuntu releases, as the archive data used in the build chroot is no longer available: Maverick (10.10)
The stable PPA is no longer updated past 1.4.0-2, except for minor bugfixes in the packaging, for the following Ubuntu releases:Lucid (10.04), Natty (11.04), Oneiric (11.10).
All releases from Precise (12.04) and onwards will still be updated, but I cannot guarantee I will be able to keep up-to-date all the time with the absolute latest release, so may need to skip a few minor revisions, depending on my availability.
This is an info-post on a Forum Council Agenda Item that Thomas Ward posted. (me).
FORUM COUNCIL AGENDA ITEM: Discussion on #ubuntuforums Moderation
In a private message with a member of the Forums Council, I stated this:
After a semi-lengthy discussion with IRCC, the jurisdictional control of #ubuntuforums was outlined as Forums Council -> IRC Council -> Community Council.
We had a small incident where there was a broken client in-channel, and ZERO moderators were around. I went to -irc and pinged for IRCC help, got nothing, ended up having to ping freenode staff for assistance.
There should be further discussion on whether additional IRC moderators are required to help handle misbehaving clients, and/or the correct steps of procedures for this.
Fortunately for the broken-client-user, they stopped flooding shortly before freenode staff responded. Therefore, incident averted, but I do believe further discussion may be prudent on this.
Given the small incident that had happened, with no moderators around, I believe further discussion should be done on how the channel can either:
- Have some type of bot or flood-protection system in place on the channel, or
- Have additional IRC moderators on the access list, or
- Have “ubuntu members” (ubuntu/member/* cloaked users) have emergency operator status to respond to such “emergency moderation” situations, or
- Some other solution decided upon by Forums Council.
While these incidents are rare, they do, however, pose issues for users who are in the channel, and for users who log everything such as myself. Flooding, even when caused by a broken client, is “spammy” and disruptive, which is why ops usually will ban-forward to ##fix_your_connection or similar.
I strongly believe that this needs to be discussed, because if it happens once, it’s likely to happen again. (And although its the holidays/end-of-year, its still a highly relevant discussion for future, whether the operators were busy with the holidays, or whether they’re just “not alive” in future).
So, this is a short post, but it should be considered.
Several IRCC meetings ago, the IRCC decided to try and run an “experiment” to move Ubuntu-related non-support out of #ubuntu-offtopic, and into #ubuntu-discuss.
While the concept was sound, and was agreed upon in a majority, there’s some… operational flaws… i think need to be discussed.
The IRCC meeting on November 25, 2012, has a discussion on this in its agenda. I won’t be there to provide my views, since i’m stuck on a bus all day that day. But, here’s my opinions:
- The concept was sound, but there was little to no encouragement for users in #ubuntu to bring ubuntu-related discussion to the discuss channel.
- Very little awareness to the community of the -discuss channel resulted in very little usage.
- Very little actual discussion was brought up in channels, and where some discussion may have occurred, nobody was there to discuss it
That’s my opinions. I’m going to email this to the irc list anyways, so that the IRCC can bring up my statements at the meeting on my behalf.
Due to LaunchPad Bug #900620, and Debian Bug 650204, the PHP package was modified in both Debian and Ubuntu (for PHP versions 5.4.0 and newer) to have php5-fpm listen on a UNIX socket by default, running at /var/run/php5-fpm.sock.
This had a “NEWS” item in debian/NEWS, but was very obscure, and not extremely recent,so this change went by semi-stealthily.
Anyone upgrading to Quantal from Precise or earlier which have servers using php5-fpm assuming that it’ll continue to listen on 127.0.0.1:9000 will need to change their configurations to adapt for this change!
In the BugSquad documentation on Bug Importance, the concept of “Core vs. Non-Core” shows up. In the past couple of months, I have brought up discussion on that topic within the BugSquad mailing list.
We seem to have come to determine that anything “core” either has a task related to it, or will show up as a dependency of the ubuntu-desktop, edubuntu-desktop, kubuntu-dekstop, etc. packages for each official derivative of Ubuntu. For example:
I’d say packages that are a part of a task should be considered core and
most other things non-core. As an example:
apt-cache show empathy | grep ^Task
Task: ubuntu-desktop, ubuntu-usb, edubuntu-desktop, edubuntu-usb
– Brian Murray, Ubuntu Bug Master
The ‘empathy’ package has tasks, specifically for ubuntu-desktop and edubuntu-desktop. It’s also listed as a dependency in the ubuntu-desktop package. That would define it as core, according to Brian Murray.
I happen to fully agree with this. If it has tasks related to a specific official derivative of Ubuntu, it should be considered core.
Note that the Bug Squad and Bug Control have not yet decided to make this as the determination of a Core or a non-Core package! This is just my opinion, stating that I agree with Brain Murray’s determination of how core/non-core should be determined!
A few weeks ago, someone posted on Ask Ubuntu asking for a minimal IPtables setup for LAMP servers.
As you can guess by the only answer there, I posted the following iptables commands for this:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p udp --dport 80 -j ACCEPT
iptables -A INPUT -j REJECT --reject-with icmp-host-unreachable
The above is extraordinarily minimal. Time to go through this, and figure out what I should have included, and what I intentionally left out.
First, we’ll look at the first command, iptables -A INPUT -i lo -j ACCEPT. This adds a rule which states that “Any traffic originating on the loopback interface, or localhost, is allowed.”.
The next rule, iptables -A INPUT -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT, uses a specialized module, called ‘conntrack’, which tracks connection states. This rule states that pre-established connections, and related connections, are accepted and not blocked.
The next rule, iptables -A INPUT -p tcp –dport 22 -j ACCEPT, accepts all traffic on port 22 (for default SSH installations and setups).
The next two rules, iptables -A INPUT -p tcp –dport 80 -j ACCEPT
and iptables -A INPUT -p udp –dport 80 -j ACCEPT, accept HTTP traffic on Port 80. Since HTTP traffic is both TCP and UDP, you need to have both.
The last rule in the above set, iptables -A INPUT -j REJECT –reject-with icmp-host-unreachable, uses a specialized target chain called “REJECT” which rejects the packets. The specific ICMP packet that will be used to reject the packet is “host unreachable” which terminates the networking connection to the server.
Now apparently, there are a few things I intentionally left out. Unless your server specifically hosts MySQL databases for external servers, you don’t need to allow MySQL traffic. Therefore, I did not add a rule to allow traffic from outside of the server itself related to MySQL (local mysql traffic is handled via the loopback rule that we first added). PHP has no reason to listen externally for requests, so it listens only on 127.0.0.1:9000 (in PHP 5.3.x, on Ubuntu Precise), or on the UNIX socket /var/run/php-fpm.sock (or similar, in PHP 5.4.x, on Ubuntu Quantal and later). Therefore, since PHP traffic will only be local, it’ll also be covered by that first rule, so no rule is needed for the PHP traffic.
I intentionally left out filtering of ICMP packets, such as pings. For an absolutely minimal setup of IPTables, you probably won’t want people to send you large pings (Pings of Death), or other ICMP packets outside of local traffic. I did not add ICMP filtering rules because I generally to not accept ICMP packets such as pings from external networks. I have a specialized program that establishes a TCP connection via HTTP and Curl automatically from my servers to one central server on an Amazon EC2 instance. The nginx access.log therefore will actually list those connections, and since I run that connection script every two minutes, its a semi-effective way of determining if the server infrastructure is online or not. If it’s not, i’ve got a nag-script that emails me if one misses a scheduled check-in several times, or if it hasnt responded in the past hour.