Come montare / tmp in / mnt su EC2?

10

Mi chiedevo quale sia il modo migliore per montare l' /tmpendpoint nella memoria /mnttemporanea su un'istanza EC2 e dare ubuntuall'utente autorizzazioni di scrittura predefinite.

Alcuni suggeriscono di modificare /etc/rc.local in questo modo:

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

Tuttavia, ciò non funziona per me (i file differiscono).

Ho provato a modificare la voce fstab predefinita:

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

sostituendo / mnt con / tmp e dandogli un umask = 0777, tuttavia non funziona a causa di cloudconfig.

Sto usando Ubuntu 12.04. Grazie.

— Claudio Poli
fonte

Non riesco a capire cosa mi stai chiedendo di fare. Potete fornire un esempio dell'output previsto usando touche ls -l?

— Jeff Ferland,

Ad esempio: l'elenco dei file in /mnt/tmpdovrebbe restituire gli stessi file /tmp, aggiungendo che un utente touch /tmp/testfilerilasciato ubuntudovrebbe funzionare senza usare sudo.

— Claudio Poli,

13

Ci sono un paio di problemi con il suggerimento iniziale che elenchi, anche se sembra che sia diretto in una buona direzione:

Per motivi di sicurezza, il mkdircomando dovrebbe creare la directory con il bit sticky impostato nella modalità:
```
mkdir -m 1777 /mnt/tmp
```
Il -o nobootwaitnon sembra necessaria in quanto tale non viene salvato in /mnt/fstab.

Quindi, consiglierei di provare questo in /etc/rc.local:

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

Qualsiasi tentativo di inserire il bind mount /etc/fstabsi imbatterà in problemi quando si interrompe / avvia l'istanza o quando si crea una AMI e si esegue una nuova istanza poiché / mnt è una memoria effimera e tutti i contenuti (inclusa la /mnt/tmpdirectory) scompaiono .

— Eric Hammond
fonte

Puoi consigliarlo di inserirlo negli script dei dati utente?

— Claudio Poli,

1

Avrei adottato l'approccio della codifica rc.local per tentare innanzitutto un montaggio del dispositivo effimero (l'aveva già montato su / mnt?), E in caso contrario, formattarlo e provare a montarlo di nuovo. In questo modo un arresto e un riavvio dovrebbero preservarlo (terminare sarebbe il modo di ricominciare da capo, come al solito). Non vedo un preciso bisogno di averlo in / etc / fstab poiché rc.local lo monta, ma avendo rc.local append probabilmente non farà male.

— Skaperen,

1

@ClaudioPoli: il problema con l'inserimento di questo in dati utente è che lo script dati utente viene eseguito solo al primo avvio. Volete che questo avvenga ad ogni avvio. Potresti avere dati utente da aggiungere a /etc/rc.local, ma assicurati che sia inserito prima di qualsiasi istruzione "exit" in quel file.

— Eric Hammond,

1

@Skaperen: / mnt è generalmente formattato in modo pulito e montato su ogni esecuzione o inizio di un'istanza. Uno stop / start ti dà un clean, fresh / mnt senza dati rimasti dalla corsa precedente. Ogni modifica che si desidera apportare a / etc / fstab verrebbe mantenuta tramite stop / start, quindi non avrebbe senso che rc.local la modifichi ad ogni avvio.

— Eric Hammond,

13

Un approccio più solido, dal momento che stai eseguendo Ubuntu, sarebbe quello di inserire il suggerimento di Eric Hammond all'interno di uno script Upstart , e di fare il bind immediatamente dopo il montaggio /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

Alcuni server, come Apache / Passenger, potrebbero creare importanti file temporanei su /tmp. Una volta rc.local, l'ultimo nella sequenza di avvio, si nascondevano e confondevano i server.

— Rômulo Ceccon
fonte

Idea intrigante ..

— Tom O'Connor

1

L'idea di usare uno script Upstart come suggerito da Romulo Ceccon è fantastica. Tuttavia, potresti non voler nascondere la magia all'interno di una sceneggiatura oscura. Va benissimo aggiungere il supporto all'interno di fstab, ad es

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

E questo è lo script 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

In questo modo, è possibile creare qualsiasi struttura di directory e cosa non nella memoria temporanea.

Tutto ciò che rimane è mkdir -p /mnt/local{1..4}un riavvio (non monterei / tmp senza come nasconderesti i file correnti lì).

— sfussenegger
fonte

Il montaggio tramite fstab avrà successo se non c'è /mnt/local1? Forse l' evento di montaggio è più sicuro.

— Rômulo Ceccon,

Sì, supponevo che / mnt / local1 fosse disponibile. Avrei dovuto spiegare che nulla è montato su / mnt, che in genere è il caso. La creazione di questa directory fa quindi parte dell'installazione. Non ho provato a utilizzare l'evento di montaggio, ma forse hai ragione. Il punto principale della mia risposta è che potrebbe essere meglio mantenere i mount nel file fstab e fare cose come gli script upstart chmod 1777o mkir -p .

— sfussenegger,