Ulimit Nofiles - Revision history

Groteblup: /* Step 2: becoming root */

2012-02-15T20:32:05Z

‎Step 2: becoming root

Groteblup: /* Step 3: wait, what? */

2012-02-15T11:08:34Z

‎Step 3: wait, what?

Groteblup: /* Step 1: your login */

2012-02-15T11:02:39Z

‎Step 1: your login

Groteblup: /* Step 3: wait, what? */

2012-02-15T11:02:07Z

‎Step 3: wait, what?

Groteblup: /* Step 1: your login */

2012-02-15T11:01:33Z

‎Step 1: your login

Groteblup: /* Step 1: your login */

2012-02-15T11:01:19Z

‎Step 1: your login

Groteblup: Created page with '= Increasing ulimit nofiles without CAP_SYS_RESOURCE = To increase the openfile descriptor limit in a vserver you must understand one thing: on a normal server uid=0 is allowed t…'

2012-02-15T11:00:16Z

Created page with '= Increasing ulimit nofiles without CAP_SYS_RESOURCE = To increase the openfile descriptor limit in a vserver you must understand one thing: on a normal server uid=0 is allowed t…'

New page

= Increasing ulimit nofiles without CAP_SYS_RESOURCE =
To increase the openfile descriptor limit in a vserver you must understand one thing: on a normal server uid=0 is allowed to do everything. Whatever you do, root is always allowed to say "override all security" on the most secure OS ever.
Then comes vserver, and it takes all those rights away. Root is a mere mortal now with some added priviliges.
One of those rights taken away is CAP_SYS_RESOURCE, which gives the right to override the hard limits set, and increase them.
Without that right, constructions will fail if not taken into account for.
== Step 0: the case ==
You are an admin, you want to log into a server and then restart a service. That service needs raised limit on open file descriptors.

== Step 1: your login ==
Most people log into a vserver using ssh as an administrator. Ssh uses pam. And pam sets your *hard* limit. The default usually is 1024.
Well, that's not a problem on normal systems, because once you gain root, you gain the right to ruin everything. This time you won't.
The ceiling is set by pam, and you cannot raise it anymore. Whatever you do now, you won't be able to raise it.
So we need to set that: in your vserver the pam limits configuration must be set for whatever you login to. On a debian system you should proably have a line like this in /etc/security/limits.conf:
@staff hard nofile 32768
This means that everyone in the administrator group staff gets a hard limit of 32768 when logging in or doing whatever.
== Step 2: becoming root ==
But wait! There is more! You are gaining root privileges, aren't you? And the tool that you uses, usually uses pam limits, to set limits for everybody, including root!
So as an administrator you got a hardlimit of 32768, and once you're root, you still lowered to 1024. Yes, we must add root as a mere mortal to the limits.conf:
root hard nofile 32768
== Step 3: wait, what? ==
I thought there was a step 3: setting a hard limit in /etc/vservers/*/ulimits/nofiles.hard , but there isn't. This is probably because the normal hard resource limit is inf. But for every default hardlimit of a resource you need raised, you should put that in the vserver configuration, which will raise the ceiling, and probably add those to limits.conf to prevent lowering the ceiling.

← Older revision		Revision as of 11:08, 15 February 2012
Line 22:		Line 22:
	== Step 3: wait, what? ==		== Step 3: wait, what? ==
	I thought there was a step 3: setting a hard limit in /etc/vservers/*/ulimits/nofiles.hard , but there isn't, at least not on my system. This is probably because the normal hard resource limit is inf. But for every default hardlimit of a resource you need raised, you should put that in the vserver configuration, which will raise the ceiling, and probably add those to limits.conf to prevent lowering the ceiling.		I thought there was a step 3: setting a hard limit in /etc/vservers/*/ulimits/nofiles.hard , but there isn't, at least not on my system. This is probably because the normal hard resource limit is inf. But for every default hardlimit of a resource you need raised, you should put that in the vserver configuration, which will raise the ceiling, and probably add those to limits.conf to prevent lowering the ceiling.
		+
		+	== Aftermath ==
		+	If you are using debian or similar which have split configuration file directories, it helps to just create a file:
		+	/etc/security/limits.d/nofiles.conf
		+	With contents like:
		+	# Allow mysql restart from ssh login
		+	@staff hard nofile 32768
		+	root hard nofile 32768

@@ Line 13: / Line 13: @@
 So we need to set that: in your vserver the pam limits configuration must be set for whatever you login to. On a debian system you should proably have a line like this in /etc/security/limits.conf:
   @staff          hard     nofile          32768
-This means that everyone in the administrator group staff gets a hard limit of 32768 when logging in or doing whatever. You can see that with:
+This means that everyone in the administrator group staff gets a hard limit of 32768 when logging in or doing whatever. You can check that with:
   ulimit -Hn

@@ Line 17: / Line 17: @@
 == Step 2: becoming root ==
-But wait! There is more! You are gaining root privileges, aren't you? And the tool that you uses, usually uses pam limits, to set limits for everybody, including root!
+But wait! There is more! You are gaining root privileges, aren't you? And the tool that you use, usually uses pam limits, to set limits for everybody, including root!
 So as an administrator you got a hardlimit of 32768, and once you're root, you still lowered to 1024. Yes, we must add root as a mere mortal to the limits.conf:
   root            hard     nofile          32768
 == Step 3: wait, what? ==
 I thought there was a step 3: setting a hard limit in /etc/vservers/*/ulimits/nofiles.hard , but there isn't, at least not on my system. This is probably because the normal hard resource limit is inf. But for every default hardlimit of a resource you need raised, you should put that in the vserver configuration, which will raise the ceiling, and probably add those to limits.conf to prevent lowering the ceiling.

@@ Line 11: / Line 11: @@
 Well, that's not a problem on normal systems, because once you gain root, you gain the right to ruin everything. This time you won't.
 The ceiling is set by pam, and you cannot raise it anymore. Whatever you do now, you won't be able to raise it.
-So we need to set that: in your vserver the pam limits configuration must be set for whatever you login to. On a debian system you should proably have a line like this in /etc/security/limits.conf:
+So we need to set that: in your vserver the pam limits configuration must be set for whatever you login to. On a debian system you should probably have a line like this in /etc/security/limits.conf:
   @staff          hard     nofile          32768
 This means that everyone in the administrator group staff gets a hard limit of 32768 when logging in or doing whatever. You can check that with: