Home / user-391990

Manish Kapoor's questions

Martin Hope
Manish Kapoor
Asked: 2019-06-06 22:32:51 +0800 CST
  • 3

Issue: My EC2 instance (used to host a tomcat based web application) goes non-responsive. It stops serving web page and does not let me login through SSH. It starts working back if I reboot it from AWS console.

Version: Ubuntu 18.04.1 LTS

Log analysis:

I found following in syslog:

systemd-networkd[621]: Failed to save lease data /run/systemd/netif/leases/2: No space left on device
systemd-networkd[621]: eth0: Failed to save link data to /run/systemd/netif/links/2: No space left on device
systemd-timesyncd[519]: Network configuration changed, trying to establish connection.
systemd-timesyncd[519]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com).
systemd-resolved[651]: Failed to write private resolv.conf contents: No space left on device
systemd-networkd[621]: Failed to save lease data /run/systemd/netif/leases/2: No space left on device
systemd-networkd[621]: eth0: Failed to save link data to /run/systemd/netif/links/2: No space left on device
systemd-networkd[621]: eth0: Could not set DHCPv4 address: Connection timed out
systemd-timesyncd[519]: Network configuration changed, trying to establish connection.
systemd-networkd[621]: eth0: Failed
systemd-timesyncd[519]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com).
systemd-resolved[651]: Failed to write private resolv.conf contents: No space left on device
systemd-networkd[621]: Failed to save network state to /run/systemd/netif/state: No space left on device

Cause:

Above logs suggest that /run goes out of space and systemd-networkd is unable to perform write operations.

Here is mount info about the /run. Currently it is using just 1% because I recorded it after the instance was rebooted and it started working again.

Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           798M  760K  797M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           798M     0  798M   0% /run/user/1000

Research:

I explored the web and found following related issues but could not get a concrete solution:

  1. /run out of space due to systemd

  2. https://unix.stackexchange.com/questions/285529/internet-stops-working-failed-to-add-run-systemd-ask-password-to-directory-wa/285532

  3. https://bugs.launchpad.net/ubuntu/+bug/1452227

Queries:

  1. What is the reason it goes out of space? Is system generating any temporary files which are not getting cleaned up ever?
  2. Currently 798M of space is allocated to /run. Is allocating more space a solution? If yes, then how much space should I allocate to it?
systemd amazon-ec2
Martin Hope
Manish Kapoor
Asked: 2015-03-27 10:13:28 +0800 CST
  • 6

Is there someway to restrict su to a specific group of users?

Upon searching over the web, I came across IBM AIX's concept of sugroup. Whenever a user is created, attribute sugroup can be set; and only members of this group are allowed to su to that user.

sugroup can help me solve my problem by creating a group which contains only certain users allowed to su. Assigning sugroup means users outside this group are not permitted to be su-ed to by other users. But this concept of sugroup is not available in Ubuntu. How can it be achieved in Ubuntu?

I made following entry in /etc/pam.d/su:

auth required pam_wheel.so group=sulogin

I created following:

  • a group called sulogin which is for users allowed to su
  • users who don't belong to sulogin are user1 and user2
  • users who do belong to sulogin are admin1 and admin2

Now when I am logged in as user1 and try to su to admin1 or admin2, I am not permitted to do so. This is as per my requirement. When I am logged in as user1 and try to su to user2, I am not permitted to do this. This is not as per my requirement (although my requirements were not clearly mentioned in the original question).

I need to restrict all the users who are not in group sulogin from su-ing to any user who belongs to sulogin group. Basically, 2 levels of su privilege. So in the above mentioned scenario:

  • user1 should be able to su to user2 and vice-versa
  • user1 or user2 should not be able to su to admin1 or admin2
  • admin1 should be able to su to user1 or user2
su