Search Results: "ag"

24 February 2012

Richard Hartmann: forcing-remote-git-rebase

Cleaning up a local repo:

git rebase -s ours -i --autosquash HEAD~20

Allowing the remote to be clobbered:

git config receive.denyNonFastForwards false

Pushing from local repo:

git push --force

Safe-guarding the remote once again:

git config receive.denyNonFastForwards true

In case you are rebasing an ikiwiki, you want to clobber the local checkout on your server, as well:

git remote update && git reset --hard @ u

Done.

Richard Hartmann: apt-get install vcsh

apt-get install vcsh I finally got around to package vcsh and David Bremner was kind enough to sponsor it. vcsh is available in testing, unstable, and squeeze-backports. Also, Ubuntu seems to have copied it over into their repositories automagically. As you probably don't know, vcsh is a tool to manage config files in git. Say you want to maintain one repository for zsh, one for vim, one for ssh, one for mplayer, and one for mr, but obviously there can only be one .git in $HOME. vcsh helps by moving $GIT_DIR into $XDG_CONFIG_HOME/vcsh/repo.d/ but keeping $GIT_WORK_TREE in $HOME. The splitting of configuration sets into separate repositories allows you avoid checking out, say, mplayer's config on your servers, or checking out your ssh config at work. If this sounds complicated, it's not; vcsh hides all of the dirty details from you. vcsh integrates nicely with mr by means of a plugin, making handling your configurations even more trivial. If you do get stuck along the way, simply drop into #vcs-home on irc.oftc.net or send email to the vcs-home mailing list. popcon tells me that there are more users than I know about directly, so pipe up if you're one of them. And if you are one of the people who have it installed but don't use it, I am even more interested. I would love to know why so I can improve it. Long story short, if you care about the integrity and/or history of your configuration, or if you use one or more computers, you should definitely give vcsh a try. Any kind of feedback appreciated :)

Dominique Dumont: Config::Model: new cme command is available

Hello I ve (finally) released a new version of Config::Model. The main change for users is the deprecation of the config-edit program in favor of cme program. Instead of using options, this cme uses command keywords like git, so users will have more possibilities while typing less. bash completion is provided for cme command and options. Following Debian annoucement regarding the recommended format of Debian copyright file (aka DEP-5), I ve also updated the URL in Debian copyright model. If your package is already in a DEP-5 format, you can update the URL with this simple command: cme fix dpkg-copyright Check the wiki on github for more example of cme command. All the best

Julien Danjou: 10 years as a Debian developer

Ten years ago, I joined the Debian project as a developer. At that time, I was 18 and in my first year at university, hanging out with the TuxFamily system administrators, which included 3 french Debian developers (sjg, igenibel and creis). I was learning Debian packaging while working on VHFFS, and decided to package one or two non-yet-packaged software for Debian. My friends pushed me into the NM process, and less than 2 months later I was a Debian developer. One have to admit that back in the days, the NM process was really fast if you were able to reply to the questions quickly. :-) I think I became the youngest developer among Debian's ones. That was my first steps in a Free Software project, and it was really exciting. In 10 years, I've been doing a lot of different things for Debian. Sure, I've been using it all the years long, but let's recap a bit what I did, from what I recall. My first Debian only project was apt-build around 2003, and later rebuildd in 2007. I built the Xen packaging team in 2005, I've been a Stable Release Manager for a year in 2006, and did heavy bug squashing to release Etch that same year. I also was an Application Manager in 2006 and managed the application of 2 Debian developers (Jose Parrella and Dami n Viano). I admit I've been less active in Debian after 2007, mainly because I was busy working on awesome, GNU Emacs and others software. Since 2011, I joined the OpenStack packaging team and I'm working on OpenStack on a (almost) daily basis. I don't know how many packages I touched, managed or updated, but that should be one or two hundreds. I still maintain 53 of them. After all, the adventure has been really pleasant, and I had the chance to work with and meet fabulous and smart people. I always liked this project and what it's trying to do. After all these years, I'm definitively staying! See you in another 10 years, folks! :)

MJ Ray: Signed the PDFreaders Petition

We, the undersigned, hereby state that we expressly and unequivocally oppose the advertising of proprietary software products on government websites. Such advertising breaches impartiality and encourages citizens to employ technologies that unnecessarily restrict their freedom. The role of government is not to support certain market participants and not others, particularly when doing so works to maintain the monopolies of global software companies. In explanations of how to use digital resources that they provide, government agencies should clarify that multiple methods are available, and favour technologies which do not restrict users digital rights; by linking to PDFreaders.org, for example. Free Software guarantees the users right to use (for any purpose), study (without secrets), share (with anyone), and improve the software that they use. Public institutions should publish their documents in formats that can be read with Free Software. Indeed, many Free Software applications exist for reading such documents. Governments should lead citizens to freedom, and encourage them to make use of these applications. Sincerely,

Our co-op and 56 other businesses, 69 organisations and over 2200 individuals so far. How about adding your signature? Surely it s time for our governments to stop giving free adverts to Adobe? It was particularly annoying in the Digital Britain report, I thought.

23 February 2012

Tanguy Ortolo: Who gave my address to spammers?

For hurried readers: do not give your main email address to Moneybookers or to deviantART, since they may give it (unintentionally, I hope) to spammers.Dedicated addresses Since I have set up my own email server, when a company or an unknown individual asks for an address I give it a dedicated one. For instance, to make a payment I had to give an address to Moneybookers: instead of giving them my main address <tanguy@>, I used <tanguy+moneybookers@>. Thanks to Postfix's address extension feature (look for recipient_delimiter in postconf(5) manpage), these <tanguy+whatever@> are all implicit aliases to my main address. This practice has several benefits, since it allows me to:

easily sort messages to dedicated mailboxes;
identify who sold or gave away my address to spammers when I start receiving tons of spam to <tanguy+moneybookers@>;
easily block that kind of spammers.

Working around lamers Some systems are coded by lamers that think the + sign is forbidden for email addresses, so I have to work around that. My current solution it to use a static alias <tanguy-2012@>, which I simply drop after a year to replace it by a new one. Two years report After two years collecting spam, the first noticeable thing is that, among 5.5k spams I received, only 78 are the result of an information leak from an organization. I excluded from that count the addresses I use in public mailing-lists, for instance <tanguy+debian@>. So, after some fine exclusion and checking of messages, these are the only two organizations that somehow gave my address to spammers:

Moneybookers: 43 spam messages received;
deviantArt: 35 spam messages received.

Jordi Mallach: alsaconf

Removing alsaconf was one of the very few rewarding moments of these ten years of taking care of ALSA in Debian. Not everyone agreed back then, and we still get some retaliation. :)

Date: Thu, 23 Feb 2012 02:59:31 +0100
From: <CENSORED>
To: jordi@debian.org
Subject: sabotage!
the removing of alsaconf without working(!) alternatives  was (AND IS!)  an
act of sabotage against millions of debian/alsa - users who needs stable
productive systems
you and all those proponents of removing this still needed alsaconf - program
will have to take the responsibility in front of an (us-) court for damages in
millions of dollars - amounts (lost man hours) all over the world
only a short while and we will have enough sponsors and witnesses around the
globe (and a very specialised, international labouring bureau of advocates) to
go to the court for prosecution.
we will not tolerate such an betray ("stable"? - do you believe, we're
fools??!!) against broad sections of the population and against the spirit of
free software!
it will be intresting to investigate, in whoms interests you've done so and
who the beneficiaries are ...
L.B.
conductor, publicist, whistleblower

Michal Čihař: Yet another project...

Okay, I'm probably really incorrigible. Not long ago, I've publicly complained that I have too many projects to work on and now I just got commit access to another one (after bothering Richard too much with my patches). Anyway I don't expect to contribute much to colorhug client, but somehow it happened that I needed to fix few bits and that lead to finding another bits to fix. Also I hope I won't have to touch much of other software in color management stack. Playing with Little CMS was nice experience, though I'd still prefer to be user in this area :-).

Filed under: English Life 0 comments Flattr this!

Niels Thykier: Some sponsors are evil and pedantic

If you want to enable all Lintian tags, just remember the phrase:

Some sponsors are evil and pedantic

Or on the command-line:

 $ lintian -EvIL +pedantic ...

It works for Lintian 2.5.5 (and newer), which handles pedantic like other severities. If you need help understanding the tags, you can add an extra i (-i) to evil . That being said, remember that experimental (-E) and pedantic (-L +pedantic) tags are what they are for a reason. Also quite a few people will probably find verbose (-v) too noisy. However, leaving any of them out would have ruined the mnemonic.

Of course, you can also ask Lintian to enable all tags via your lintianrc file. Here is a quick-start:

display-info = yes # or no
display-experimental = yes # or no
pedantic = yes # or no
verbose = yes # or no

Russ Allbery: Debian Policy 3.9.3.0

I've just uploaded version 3.9.3.0 of Debian Policy. The really big change in this version is the 1.0 version of the copyright format specification, but that will get a separate announcement once the www team has had a chance to put it in place on the web site. There are a bunch of other fixes, though, including some normative changes. Here's the upgrading checklist (duplicated from my announcement, but formatted a bit prettier):

2.4: New archive sections education, introspection, and metapackages added.
5.6.8: The Architecture field in *.dsc files may now contain the value any all for source packages building both architecture-independent and architecture-dependent packages.
7.1: If a dependency is restricted to particular architectures, the list of architectures must be non-empty.
9.1.1: /run is allowed as an exception to the FHS and replaces /var/run. /run/lock replaces /var/lock. The FHS requirements for the older directories apply to these directories as well. Backward compatibility links will be maintained and packages need not switch to referencing /run directly yet. Files in /run should be stored in a temporary file system.
9.1.4: New section spelling out the requirements for packages that use files in /run, /var/run, or /var/lock. This generalizes information previously only in 9.3.2.
9.5: Cron job file names must not contain "." or "+" or they will be ignored by cron. They should replace those characters with "_". If a package provides multiple cron job files in the same directory, they should each start with the package name (possibly modified as above), "-", and then some suitable suffix.
9.10: Packages using doc-base do not need to call install-docs anymore.
10.7.4: Packages that declare the same conffile may see left-over configuration files from each other even if they conflict.
11.8: The Policy rules around Motif libraries were just a special case of normal rules for non-free dependencies and were largely obsolete, so they have been removed.
12.5: debian/copyright is no longer required to list the Debian maintainers involved in the creation of the package (although note that the requirement to list copyright information is unchanged).
copyright-format: Version 1.0 of the "Machine-readable debian/copyright file" specification is included.
mime: This separate document has been retired and and its (short) contents merged into Policy section 9.7. There are no changes to the requirements.
perl: Packages may declare an interest in the <perl-major-upgrade> trigger to be notified of major upgrades of perl.
virtual: ttf-japanese- mincho,gothic have been renamed to fonts-japanese- mincho,gothic .

Please review and update your packages as necessary the next time you make an upload.

Paul Tagliamonte: Intent to become a Debian Developer

Howdy! I d like to officially state (for the record) that it is my intent to apply to become a Debian Developer within the next $TIMEFRAME. Currently soliciting advice and opinions before nm.d.o comes back online :) It s a big step, but it s a natural one. Gametime?

22 February 2012

Bernd Zeimetz: nagios-plugins-contrib released

Nagios or Icinga users probably know the problem that neither the default plugin packages (nagios-plugins-basic and -standard) nor the few other plugin packages ship all the plugins you need to monitor your hardware and software properly. And unless you have puppet, cfengine or some other automation software, you probably just start searching plugins on Nagios Exchange, MonitoringExchange or some other machines you are monitoring already. Your problem shall be solved! nagios-plugins-contrib passed NEW today. It is a collection of various useful plugins, maintained within the Debian Nagios Maintainer Group. So far it contains only 6 plugins (check_email_delivery, check_ipmi_sensor, check_lm_sensors, check_memcached, check_raid, check_rbl), but more are going to come.

To have your favorite plugins added to the package we would like to encourage you to send pull requests, either using github, alioth or your personal repository. Please keep in mind that you'll be added to the Uploaders of the package automatically to ensure that you keep your plugin updated and in a good shape. See debian/README.source for some instructions on adding new plugins. Unmaintained plugins will be removed! Of course you can also submit bug reports to have a new plugin added, but you have to convince somebody to maintain it for you (or that he wants to use the plugin and needs to maintain it therefore

). We might also also have a similar package in contrib as a lot of commonly used plugins require non-free software, so don't hesitate to prepare plugins for inclusion in such a package and let us know! Suggestions and ideas for improvement are always welcome. And so is help to maintain the packages!

Bartosz Feński: [B]ack[U]p and [R]estore [P]rogram

One of the most popular backup solution under Linux is Bacula, but it s quite complicated to setup. The same for Amanda.
Since my last sponsored upload we ve got another alternative in Debian. It s called burp. Let s enumerate its features as of version 1.3.0:

Server mode runs on Unix-based systems.
Client mode runs on Windows and Unix-based systems.
Windows Volume Shadow Copy Service (VSS) support (Windows XP R2 and newer).
Windows 32bit and 64bit support.
Delta differencing with librsync.
Network backups.
Backs up and restores files, directories, symlinks, hardlinks, fifos and nodes.
Storage and network compression using zlib.
Ability to continue interrupted backups.
Client/server communications encryption with SSL.
Client side file encryption (note: this turns off delta differencing).
Scheduling.
Email backup success/failure notifications.
A single daily backup summary email.
A live ncurses monitor on the server.
Fifo read/write support.
Pre/post backup/restore client scripts.
Backups of Solaris ZFS snapshot send/receives.
Linux and FreeBSD acl/xattr support.
Multiple retention periods (e.g, keep 1 backup per day for 7 days, 1 backup per week for 4 weeks, 1 backup per 4 weeks for a year).
Network rate limiting.
Storage data deduplication.
Automatic client upgrade.

Sounds good and this project is only 1 year old! Author claims that setup is much easier than with Bacula. Let s find out is that truth

Since we ve got this software in Debian installing it on unstable is as simple as apt-get install burp .
Both client and server came from the same binary package. Now let s configure server side. Well in fact we just have to run it, so just change RUN=no to RUN=yes in /etc/default/burp and launch it using /etc/init.d/burp start . Now the client side. If the client is on the same machine then you re ready. Yes you re ready! Let s do our first backup:

backup ~ # burp -a b
2012-02-22 17:53:03: burp[30584] Listing configured paths:
2012-02-22 17:53:03: burp[30584] include: /home
2012-02-22 17:53:03: burp[30584] Listing starting paths:
2012-02-22 17:53:03: burp[30584] /home
2012-02-22 17:53:03: burp[30584] before client
2012-02-22 17:53:03: burp[30584] begin client
2012-02-22 17:53:03: burp[30584] auth ok
2012-02-22 17:53:03: burp[30584] Compression level: 9
2012-02-22 17:53:03: burp[30584] do backup client
2012-02-22 17:53:03: burp[30584] Phase 1 begin (file system scan)
 
ddwdffffddffdfdfdddfffffdddfffffffdfffdfdfffffdfdfdffdddddfffddff 64
[...a lot of output...]
 
2012-02-22 17:53:03: burp[30584] Phase 1 end (file system scan)
2012-02-22 17:53:03: burp[30584] Phase 2 begin (send file data)
 
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 64
[...a lot of output...]
 
--------------------------------------------------------------------------------
Start time: 2012-02-22 17:53:03
  End time: 2012-02-22 17:53:07
Time taken: 00:04
                             New   Changed Unchanged     Total    Scanned
                       --------------------------------------------------
                Files:       100         0         -       100        100
          Directories:         -         -         -         -         76
           Soft links:         -         -         -         -          1
          Grand total:       100         0         -       100        177
                       --------------------------------------------------
 
             Warnings:             1
 
      Bytes estimated:      17628946 (16.81 MB)
      Bytes in backup:      17628946 (16.81 MB)
       Bytes received:             0
           Bytes sent:      17628946 (16.81 MB)
--------------------------------------------------------------------------------
2012-02-22 17:53:07: burp[30584] Phase 2 end (send file data)
2012-02-22 17:53:07: burp[30584] backup finished ok
2012-02-22 17:53:07: burp[30584] after client
backup ~ #

Yes. By default it is so extremely simple! Of course this way we can make backup of /home (that s default) to /var/spool/burp (also default location) but you can easily change this.
For the simplest scenario (backing up laptop to remote server) all I had to change was server = 127.0.0.1 in /etc/burp/burp.conf on the client side. Burp comes with handy tool called burp_ca and it simplifies setting up encrypted backups. In fact there is step by step howto in documentation.
Other options are quite self explanatory and well documented in both client and server config files that came with the package. Happy backuping!

Christian Perrier: 2012 update 11 for Debian Installer localization

Estonian reaches 100% in level 1
24 other languages back to 100% in level 1 and 6 are again fully complete
Irish progress in level 1
Catalan progress in level 1
Tamil progress in level 2

Status for D-I level 1 (core D-I files):

25 languages 100%: bg bs cs de el eo es et fa fr gu id it ja kk mr nl pl pt ru sk sr th tr zh_CN
12 languages 99%: ar ast hi km kn ko nb si sv ta te uk
1 language 97%: eu
3 languages 96%: be ga he
5 languages 95%: bn da dz ro zh_TW
1 language 94%: ca
3 languages 93%: hu is lo
1 language 92%: sl
2 languages 91%: pa vi
others are 90% or below

Status for D-I level 2 (packages that have localized material that may appear during default installs, such as iso-codes, tasksel, etc.):

23 languages 100%: bg cs da de eo es fa fr he id is it ja kk nl pl pt ru si sk tr uk zh_CN
4 languages 99%: be sl sv th
6 languages 98%: ast dz ca eu pt_BR ro
1 language 97%: ta
1 language 96%: nb
2 langauges 95%: el fi
5 languages 94%: ar gl hr vi zh_TW
6 languages 92%: bn bs hu ko ne sr
8 languages 91%: ga gu ka km lt mk mr te
others are 90% or below

Status for D-I level 3 (packages that have localized material that may appear during non-default installs, such as win32-loader)

31 languages 100%: be bg bs ca cs de el eo es fa fi fr ga gl he id is it ja kk nb nl pl pt ru sk sr sv th tr zh_CN
2 languages 98%: hu uk
others are 90% or below

Full 100% completeness (hall of fame) for 18 languages: Bulgarian, Czech, German, Esperanto, Spanish, Persian, French, Indonesian, Italian, Japanese, Kazakh, Dutch, Polish, Portuguese, Russian, Slovak, Turkish, Simplified Chinese

Michal Čihař: Secure your phpMyAdmin

phpMyAdmin is quite popular software (to give some numbers let's mention 10000 downloads daily on SourceForge.net or 122685 reports in Debian's popcon) and as such is quite attractive target for various scripted attacks. If you run phpMyAdmin installation somewhere you should really make sure it is enough secured, so that these script kiddies don't get through. In past month I've looked at what kind of attacks are these guys trying and in all cases these are pretty old vulnerabilities, some of them fixed years ago. So the first thing you should do is to update. It is always good to run latest stable version, but in case you can not for whatever reason, try at least taking the most important fixes and using them. In ideal world your distribution would do this job for you, but in case it did not, you can for example take patches from Debian, which is pretty good at taking our patches (surprisingly it is not much related to my involvement there). To check which patches they have applied you can use excellent patch-tracker tool, which exposes patches from all released packages. To give you overview of which issues are mostly being attempted to exploit by script kiddies right now, here is the list:

PMASA-2010-3 - yes, more than two years old, but still unpatched in some places
PMASA-2011-5 - "only" half year old
PMASA-2011-6 - only useful together with wrongly configured PHP

If you have fixed these, you should be pretty safe for now, but follow our security announcements for possible future issues (you can use RSS feed or subscribe to news mailing list, where all security issues are announced as well). However there are more things you can do to keep you safer:

remove setup directory from phpMyAdmin, you will probably not use it after initial setup
prevent access to libraries directory from browser, as it is not needed, supplied .htaccess file does this
properly choose authentication method - cookie is probably the best choice for shared hosting
in case you don't want all MySQL users to be able to access phpMyAdmin, you can use AllowDeny rules to limit them
consider hiding phpMyAdmin behind authentication proxy, so that MySQL credenticals are not all users need to login

So these are the basic steps which will help you against possible compromise, I might return to some of these in more details in future posts.

Filed under: Debian English Phpmyadmin Suse 0 comments Flattr this!

Cyril Brulebois: Wrench days

Fixing hardware

Thanks to the nice Debian Swiss Knives initiative! Fixing software Besides trying to maintain the whole X stack as usual, and preparing the funky wayland, mesa, and weston trio for experimental, I got myself into other areas. Debugging gzip Jakup Wilk noticed a while ago that some multiarchified packages couldn t be co-installed due to gzipped files being different between architectures. That was reported as #647522 against the gzip package. While some developers consider the lack of determinism (as in: it s not in the gzip specification, and the current implementation generates different packages anyway!) as a dead-end for the multiarch experiment, it didn t look like undebuggable or unfixable. And indeed, as confirmed by a quick analysis: a lack of clean-up when several files are processed at once can lead to different results, depending on the order in which files are specified on the command line; the patch for that is trivial, and was later made smaller and the need for it was explained. Working in the Release Team I reviewed/approved a few packages for squeeze, but also took care of handling or finishing a few transitions (as seen in my hints file), among which the funny iceweasel9/libmozjs ones; release tools are nice, but one gets to learn lots of stuff at once (which isn t a negative aspect). I hacked a tiny collision detector so that packages involved in several transitions can be easily spotted. Given the huge number of ongoing transitions we had lately, that didn t look overkill. Squashing bugs It had been a very long time since my last working on totally random RC bugs. The Bug Squashing Party organized at IRILL was a very nice opportunity to get back to totally crazy bugs in unknown packages, but also to meet with other Debian contributors; sponsoring maintainers with good patches on their first try was nice, but walking other contributors through their first patches sent to the BTS or through their first NMUs was nice too. Waving good bye to yada Back in the M rida QA meeting I attended in 2007, there were already jokes about how bad yada was, and how it should die in a fire etc. When I started looking at the RC bug list, I quickly switched to scrolling it backwards, and I wondered how much work was left. The details can be seen in #660548, and the result is: yada is gone! sanity++; packages.debian.org Both long descriptions and translations for packages in some suites disappeared after the switch to Description-md5. Thanks to a quick and reduced packages.debian.org setup (mostly: en+de for squeeze+sid+experimental), I managed to find my way through Perl and DB files to propose patches for #657557. I m still waiting for a confirmation, but in case it works fine, we could even get a fix for DDTP/DDTSS.

21 February 2012

Aigars Mahinovs: Le Camp Le DebConf Le 2013!

The meeting was as long as the kernel changelog, the decision was as difficult as a Debian release, but in the end Le Camp has won in the voting 5 to 4. It was lucky that one member of the 10 man committee was not present or we could have had a tie, just like there was one in the first round of voting. Well, congratulations to the poor sods of the Swiss team, who will now have to fulfil what they promised and also all the small things that everyone always forgets that also need to be done for every Debconf! I think that I will try again for 2015, but before that we will try to get a few people from Latvian community to go to Debconf13 to get the Debconf and Debian experience and exposure. Meanwhile, it looks like I will be skipping this years Debconf12 it is very far away for me and as I could not find a reasonable business rationale for me being there, it would be a far and expensive vacation for me. I don t think there is enough benefit from me being there to ask for any Debian funds for this either, especially hearing how tight money is this year. So if you re going, make sure to take a camera and take a bunch of pictures, so we at home can see it too

Michal Čihař: Cleaning up websites, say goodbye to Twitter

Finally I've found some time to do small cleanup on my websites. First of all I've removed links to my Twitter and Identi.ca profiles as they are dead and I don't think I'm going to make them alive any time soon. I never really got into this business and only used it as one interface to feed posts to Facebook (via Identi.ca's app there). Together my mostly read only Facebook usage, there is nothing going on there. While touching the website code, I also did some cleanup on Wammu website (where Twitter and Identi.ca still stays as announcement media for new versions). Most notable change is that I've reduced usage of external (and in times heavy) javascript and links to social media are now just static HTML, which also nicer fit into website layout. It did indeed remove several options, but I don't think these were worth of the load it introduced.

Filed under: English Gammu 0 comments Flattr this!

Francois Marier: Putting a limit on Apache and PHP memory usage

A little while ago, we ran into memory problems on mahara.org. It turned out to be due to the GD library having issues with large (as in height and width, not file size) images.

What we discovered is that the PHP memory limit (which is set to a fairly low value) only applies to actual PHP code, not C libraries like GD that are called from PHP. It's not obvious what PHP libraries are implemented as external C calls, which fall outside of the control of the interpreter, but anything that sounds like it's using some other library is probably not in PHP and is worth looking at.

To put a cap on the memory usage of Apache, we set process limits for the main Apache process and all of its children using ulimit.

Unfortunately, the limit we really wanted to change (resident memory or "-m") isn't implemented in the Linux kernel. So what we settled on was to limit the total virtual memory that an Apache process (or sub-process) can consume using "ulimit -v".

On a Debian box, this can be done by adding this to the bottom of /etc/default/apache2:

ulimit -v 1048576

for a limit of 1GB of virtual memory.

You can ensure that it works by setting it first to a very low value and then loading one of your PHP pages and seeing it die with some kind of malloc error.

I'm curious to know what other people do to prevent runaway Apache processes.

Russ Allbery: Debian packaging updates

Now is the point in the Debian release cycle where I usually try to go through my packages and bring them generally up to date. In case other people are doing the same thing, here are a few new facilities or techniques that I'm rolling out across my packages. (This is apart from the obvious stuff, like multiarch where appropriate and debhelper 9, and the older stuff, like using dh.)

dh-autoreconf is a new helper tool that runs autoreconf on the package during the build and cleans up properly afterwards. I've started switching all of my packages that use Autoconf and Automake and can use autoreconf over to it. (Some upstreams have more complex scripts that have to be run to regenerate the build system.) It plugs in trivially as a dh add-on, and even adds support for --as-needed (see below). I'm doing this even for packages where I don't patch the build system, on the grounds that rebuilding everything from source, including the build system, is a good idea. It also means that I can patch the build system when I need to without having to add additional machinery at the time.
Linking with --as-needed. As I build new packages, I'm looking for anything that has warnings about generating unnecessary dependencies and adding --as-needed to the linker flags. The combination of dh-autoreconf and the new dpkg-buildflags support makes this trivial to do for most packages. Just add something like:
```
    export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
```
to debian/rules. It's worth being aware that --as-needed can break some unusual uses of special cases around shared library loading, but I've not run into any of those cases with any of the software that I package.
dpkg-buildflags comes essentially for free with debhelper 9, but it's worth mentioning that, as mentioned above, it's a really easy way to add additional flags. And if you have to pass in flags via some other mechanism, use dpkg-buildflags to get the default flags.
Once you're up to debhelper 9 and are using dpkg-buildflags, adding hardening flags is easy. You get the default ones for free, and that's a pretty good start. (Install hardening-includes and use hardening-check to check the status of the binaries built by your package.) I always add at least hardening=+bindnow to DEB_BUILD_MAINT_OPTIONS (set with export in debian/rules), since the minor speed hit at startup doesn't matter for anything that I'm packaging. (It might for something like ls that runs all the time.) I usually try to also add +pie, but be careful of that. Libtool will cope correctly with it and switch it back to PIC for shared libraries, but other shared library build processes may not. And it doesn't always work; for example, gnubg (GNU Backgammon) just immediately dies if built PIE, for reasons that I didn't track down.
If, like me, you maintain your packaging in Git without using a separate tool that exports a patch series, and therefore use the single-debian-patch option, there is new support for applying that option only to your build as the maintainer but not to any other build that people do of your source package. This is good, since it means that any NMU diffs will be kept separate from your maintainer diff because they'll get the version of the NMU package added. To get this behavior, move debian/source/patch-header to debian/source/local-patch-header and debian/source/options to debian/source/local-options (assuming that's your only option; otherwise, you might need to split it). Then the patch header and options won't be included in the generated source package and hence won't apply to NMUs or other packaging changes based on the source package in the archive instead of on the packaging repository.

It's also worth mentioning that Ubuntu was responsible for breaking a lot of ground here. Due to bug reports and patches submitted from Ubuntu, several of my packages already had hardening build flags and --as-needed issues fixed before this round of packaging refresh, which made adding these features much easier than it would be otherwise.

Next.

Previous.