Как смонтировать / tmp в / mnt на EC2?


10

Мне было интересно, как лучше монтировать /tmpконечную точку в эфемерном хранилище /mntна экземпляре EC2 и дать ubuntuпользователю права на запись по умолчанию.

Некоторые предлагают отредактировать /etc/rc.local таким образом:

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

Однако это не работает для меня (файлы отличаются).

Я попытался редактировать запись fstab по умолчанию:

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

заменив / mnt на / tmp и присвоив ему umask = 0777, однако он не работает из-за cloudconfig.

Я использую Ubuntu 12.04. Спасибо.


Я не могу понять, что ты просишь меня сделать. Можете ли вы привести пример ожидаемого результата, используя touchи ls -l?
Джефф Ферланд,

Например: перечисление файлов в /mnt/tmpдолжно возвращать те же файлы /tmp, добавляя, что touch /tmp/testfileвыданные ubuntuпользователем должны работать без использования sudo.
Клаудио Поли

Ответы:


13

Есть пара проблем с первоначальным предложением, которое вы перечисляете, хотя кажется, что оно движется в правильном направлении:

  1. В целях безопасности mkdirкоманда должна создать каталог с установленным в режиме липким битом:

    mkdir -m 1777 /mnt/tmp
    
  2. -o nobootwaitНе представляется необходимым , поскольку это не сохраняется в /mnt/fstab.

Итак, я бы рекомендовал попробовать это в /etc/rc.local:

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

Любая попытка вставить связывающее монтирование может привести /etc/fstabк проблемам при остановке / запуске экземпляра или при создании AMI и запуске нового экземпляра, поскольку / mnt является эфемерным хранилищем, а все содержимое (включая /mnt/tmpкаталог) исчезнет. ,


Можете ли вы порекомендовать включить это в сценарии пользовательских данных?
Клаудио Поли

1
Я бы использовал подход кодирования rc.local, чтобы сначала попытаться смонтировать эфемерное устройство (он уже смонтировал его в / mnt?), А если это не удалось, отформатируйте его и попробуйте снова смонтировать. Таким образом, остановка и перезапуск должны сохранить его (прекращение будет способом начать все заново, как обычно). Я не вижу определенной необходимости иметь его в / etc / fstab, так как rc.local монтирует его, но добавление rc.local, вероятно, не повредит.
Skaperen

1
@ClaudioPoli: проблема с размещением этого в пользовательских данных заключается в том, что сценарий пользовательских данных запускается только при первой загрузке. Вы хотите, чтобы это работало при каждой загрузке. Пользовательские данные можно добавить в /etc/rc.local, но убедитесь, что они вставлены перед любым оператором «выхода» в этом файле.
Эрик Хаммонд,

1
@Skaperen: / mnt обычно корректно форматируется и монтируется при каждом запуске или запуске экземпляра. Останов / запуск дает вам чистый, свежий / Mnt без данных, оставшихся от предыдущего запуска. Любая модификация, которую вы хотите сделать в / etc / fstab, будет сохранена через stop / start, поэтому не имеет смысла, чтобы rc.local изменял ее при каждой загрузке.
Эрик Хаммонд

13

Более надежный подход, так как вы работаете в Ubuntu, будет ставить предложение Эрика Хаммонда внутри Upstart сценария, и имеет привязку сделать сразу после установки /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

Некоторые серверы, такие как Apache / Passenger, могут создавать важные временные файлы /tmp. Один раз rc.local- последний в последовательности загрузки - запускался, они скрывались и приводили в замешательство серверы.


Интригующая идея ..
Том О'Коннор

1

Идея использования сценария Upstart, предложенная Ромуло Цекконом , великолепна. Тем не менее, вы можете не захотеть скрывать магию внутри неясного сценария. Вполне нормально добавить крепление внутри fstab, например

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

И это сценарий Upstart:

# 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

Таким образом, вы можете создать любую структуру каталогов, а не какую-либо временную память.

Все, что осталось, mkdir -p /mnt/local{1..4}это перезапустить (я бы не монтировал / tmp без, как вы бы там прятали текущие файлы).


Удастся ли монтировать через fstab, если нет /mnt/local1? Возможно, монтажное мероприятие безопаснее.
Ромуло Цеккон,

Да, я предположил, что / mnt / local1 доступен. Я должен был объяснить, что на / mnt ничего не монтируется, как это обычно бывает. Поэтому создание этого каталога является частью настройки. Я не пробовал использовать событие монтирования, но, возможно, вы правы. Суть моего ответа заключается в том, что может быть лучше сохранить монтирование в файле fstab и выполнять такие вещи, как сценарии chmod 1777or или mkir -p upstart.
sfussenegger
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.