I’ve created a /tmp partition on a server that I would like to encrypt in a fashion that doesn’t require a password to be entered on boot because this server is in a remote data center.
Storing the password on the server so that it can automatically boot would obviously defeat the purpose of encrypting in the first place. Skipping automounting is another option but I’d really like to avoid that because there are a number of other services that would have to be suspended until the /tmp partition is online.
I found this article designed for centos (HowTos/EncryptTmpSwapHome - CentOS Wiki) which seems perfect since it generates a key randomly on boot and that key is destroyed and regenerated on each successive boot. However, the script doesn’t seem to work on openSUSE - it throws errors saying . /etc/init.d/functions doesn’t exist, restorecon command not found, action command not found, etc.
Is there an openSUSE-ish way to achieve promptless partition encryption?
/etc/init.d/functions: No such file or directory not sure if that’s important or not
mount: you must specify the filesystem type
action: command not found
I do think the problem is the fact we do not have the script file:
/etc/init.d/functions: No such file or directory not sure if that's important or not
Which means you will have to find a different solution or find a copy of this file to see just what it is doing. I tried to find it, but I did not come across the actual file, only references to a file by that name in other scripts.
Yeah I was able to find the functions file on a CentOS virtual box instance. It’s VERY CentOS/RHEL specific so it looks like it’s off to find another solution - ideas would be greatly appreciated!
Yeah I was able to find the functions file on a CentOS virtual box instance. It’s VERY CentOS/RHEL specific so it looks like it’s off to find another solution - ideas would be greatly appreciated!
Thanks,
Dan
You are welcome Dan. I am not a big fan of such encryption as it can render your data useless when it does not work, though doing what you suggest does not seem that bad. I think you need to start a new thread and request help on finding some sort of encryption you can use with openSUSE instead of trying to get a solution intended for a different Linux Distribution to work with openSUSE. Good Luck.
I may be off in left field, but what would be the point of encrypting
something like /tmp without getting the other sensitive areas of the hard
drive? I presume protection from theft (don’t want to see what was in
/tmp if the drive is stolen) is a compelling reason and it makes sense,
but what about the source of those sensitive data (the other drive’s
partitions)? I presume you are not mounting volumes remotely which would
be a bit weird with a local /tmp volume. Anyway, just not seeing how much
benefit you will get from this.
Good luck.
On 01/27/2011 09:06 PM, dancablam wrote:
>
> Thanks again, James. That’s exactly what I’ll do.
>
> Cheers,
> Dan
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
For our application /tmp is really the only place that sensitive information originates. Client upload files via HTTPS that are stored in /tmp before being compressed, encrypted and uploaded to Amazon S3 for permanent storage.
Have you considered somehow using a ramdisk instead? I use /dev/shm all
of the time (I’m going to find out a reason that it’s a terrible thing to
do one of these days and be really sad as it’s sooo convenient) and I’m
pretty sure as long as I have RAM to back it the files never touch disk so
when the box goes down the data are gone. A specifically-setup ramdisk
for /tmp would do the same thing… or just symlink /tmp to /dev/shm.
Good luck.
On 01/28/2011 01:06 AM, dancablam wrote:
>
> ab@novell.com;2283377 Wrote:
>>
>> I may be off in left field, but what would be the point of encrypting
>> something like /tmp without getting the other sensitive areas of the
>> hard
>> drive?
>
> For our application /tmp is really the only place that sensitive
> information originates. Client upload files via HTTPS that are stored in
> /tmp before being compressed, encrypted and uploaded to Amazon S3 for
> permanent storage.
>
> Cheers,
> Dan
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/