10

I was wondering what is the best way to mount the /tmp endpoint in the ephemeral storage /mnt on an EC2 instance and give the ubuntu user default write permissions.

Some suggest editing /etc/rc.local this way:

mkdir -p /mnt/tmp && mount --bind -o nobootwait /mnt/tmp /tmp

However that doesn't work for me (files differs).

I tried editing the default fstab entry:

/dev/xvdb /mnt auto defaults,nobootwait,comment=cloudconfig 0 2

replacing /mnt with /tmp and and giving it a umask=0777, however it doesn't work because of cloudconfig.

I'm using Ubuntu 12.04. Thanks.

Claudio Poli
  • 285
  • 3
  • 10
  • I can't figure out what you're asking me to do. Can you provide an example of the expected output using `touch` and `ls -l`? – Jeff Ferland Sep 14 '12 at 21:42
  • For example: listing files in `/mnt/tmp` should return the same files in `/tmp`, adding that a `touch /tmp/testfile` issued from the `ubuntu` user should work without using `sudo`. – Claudio Poli Sep 14 '12 at 21:45

3 Answers3

13

There are a couple problems with the initial suggestion you list, though it seems like it's headed in a good direction:

  1. For security purposes, the mkdir command should create the directory with the sticky bit set in the mode:

    mkdir -m 1777 /mnt/tmp

  2. The -o nobootwait doesn't seem necessary as this is not being saved in /mnt/fstab.

So, I'd recommend trying this in /etc/rc.local:

test -d /mnt/tmp || mkdir -m 1777 /mnt/tmp
mount --bind /mnt/tmp /tmp

Any attempt to put the bind mount in /etc/fstab is going to run into problems when you stop/start the instance or when you create an AMI and run a new instance as /mnt is ephemeral storage and all contents (including the /mnt/tmp directory) are going to disappear.

Eric Hammond
  • 10,901
  • 34
  • 56
  • Can you recommend putting this in user-data scripts? – Claudio Poli Sep 15 '12 at 02:38
  • 1
    I would take the approach of coding rc.local to first attempt a mount of the ephemeral device (did he already mount it at /mnt ?), and if that fails, format it and try mounting again. That way a stop and restart should preserve it (terminate would be the way to start fresh, as usual). I don't see a definite need to have it in /etc/fstab since rc.local mount it, but having rc.local append it probably won't hurt. – Skaperen Sep 15 '12 at 04:02
  • 1
    @ClaudioPoli: The problem with putting this in user-data is that the user-data script is only run on the *first* boot. You want this to run on *every* boot. You could have user-data add this to /etc/rc.local, but make sure it's inserted before any "exit" statement in that file. – Eric Hammond Sep 15 '12 at 21:47
  • 1
    @Skaperen: /mnt is generally formatted cleanly and mounted on every run or start of an instance. A stop/start gives you a clean, fresh /mnt with no data left over from previous running. Any modification you wanted to make to /etc/fstab would be preserved through stop/start, so it would not make sense to have rc.local modify it on every boot. – Eric Hammond Sep 15 '12 at 21:53
13

A more robust approach, since you're running Ubuntu, would be to put Eric Hammond's suggestion inside an Upstart script, and have the bind done immediately after mounting /mnt:

# File /etc/init/mounted-mnt.conf

# mounted-mnt - Binds /tmp to /mnt/tmp

description     "Binds /tmp to /mnt/tmp"

start on mounted MOUNTPOINT=/mnt

task

script
    test -d /mnt/tmp || mkdir -m 1777 /mnt/tmp
    mount --bind /mnt/tmp /tmp
end script

Some servers, like Apache/Passenger, might create important temporary files on /tmp. Once rc.local – the last in the boot sequence – ran they would get hidden and confuse the servers.

Community
  • 1
Rômulo Ceccon
  • 253
  • 2
  • 8
1

The idea of using an Upstart script as suggested by Romulo Ceccon is great. However, you may not want to hide the magic inside an obscure script. It's perfectly ok to add the mount inside fstab, e.g.

LABEL=cloudimg-rootfs   /    ext4   defaults    0 0

# auto mount ephemeral storage (if any)
# init contents in /etc/init/mounted-local*.conf
/dev/xvdb  /mnt/local1  auto  defaults,nofail,nobootwait,comment=cloudconfig  0 2
/dev/xvdc  /mnt/local2  auto  defaults,nofail,nobootwait,comment=cloudconfig  0 2
/dev/xvdd  /mnt/local3  auto  defaults,nofail,nobootwait,comment=cloudconfig  0 2
/dev/xvde  /mnt/local4  auto  defaults,nofail,nobootwait,comment=cloudconfig  0 2

# bind /tmp to /mnt/local1, might still be on / if no ephemeral storage
/mnt/local1  /tmp  none  bind

And this is the Upstart script:

# File /etc/init/mounted-local1.conf

# mounted-local1 - init ephemeral storage in /mnt/local1

description     "Initializes ephemeral storage in /mnt/local1"

start on mounted MOUNTPOINT=/mnt/local1

# provide defult, see /etc/init/mounted-tmp.conf for details
env MOUNTPOINT=/mnt/local1

task

script
    # fix permissions if needed
    test -d $MOUNTPOINT && chmod 1777 $MOUNTPOINT

    # log to /var/log/upstart/mounted-local1.log
    #echo "initialized $MOUNTPOINT"

end script

This way, you could create any directory structure and what not on ephemeral storage.

All that's left is mkdir -p /mnt/local{1..4} and a restart (I wouldn't mount /tmp without as you would hide current files there).

Community
  • 1
sfussenegger
  • 8,462
  • 1
  • 15
  • 7
  • Will the mount via fstab succeed if there's no `/mnt/local1`? Perhaps the [mounting](http://manpages.ubuntu.com/manpages/precise/en/man7/mounting.7.html) event is safer. – Rômulo Ceccon May 12 '14 at 14:13
  • Yes, I assumed that /mnt/local1 is available. I should have explained, that nothing is mounted on /mnt which typically is the case. Creating this directory therefore is part of the setup. I haven't tried using the mounting event, but maybe you are right. The main point of my answer is that it might be better to keep mounts in the fstab file and do stuff like the `chmod 1777` or `mkir -p ` in upstart scripts. – sfussenegger May 15 '14 at 09:40