Solved zfs dataset for web hosting

fred974

fred974

Hi,
I am using zfs file system on my server and I would like to know if other than MySQL, if there are any recommendation to follow for the webfiles (wordpress and shtml)

For MySQL I created
Code: 
zfs create zroot/DATA
zfs set mountpoint=none zroot/DATA
zfs create -o recordsize=8k zroot/DATA/mysql
zfs create -o recordsize=128k -o primarycache=metadata zroot/DATA/mysql/mysql-innodb-logs
zfs create -o recordsize=16k -o primarycache=metadata zroot/DATA/mysql/mysql-innodb
What would the dataset be for webfile?
is it simply zfs create zroot/DATA/www with no argument? Do I need compression or a record size?

Thank you in advance
Fred
 
I would just create the filesystem, no options. You could enable compression but that depends a bit on the content. If most of it is plain text (HTML, PHP, etc) it will compress pretty good. Other than that I usually don't use any other options.
 
Thank you SirDice
Just to clarify and i'll close the post.. should I be using:
Code: 
zfs create zroot/DATA/www/
zfs create -o compression=lz4 zroot/DATA/www/firstdomain
zfs create -o compression=lz4 zroot/DATA/www/seconddomain2
OR
Code: 
zfs create zroot/DATA/www/
zfs create -o compression=on zroot/DATA/www/firstdomain
zfs create -o compression=on zroot/DATA/www/seconddomain2
 
I'm not entirely sure what the default compression is actually. But in any case, LZ4 seems to be the best performing one.
 
According to zfs(8) the default is lzjb. It also recommends using lz4 instead if supported:
Setting compression to on uses the lzjb compression algorithm.
[...]
The lz4 compression algorithm is a high-performance replacement for
the lzjb algorithm. It features significantly faster compression and
decompression, as well as a moderately higher compression ratio than
lzjb, but can only be used on pools with the lz4_compress feature set
to enabled. See zpool-features(7) for details on ZFS feature flags
and the lz4_compress feature.
Click to expand...
 
Could someone please clarify something for me
Code: 
zfs create -o compression=on zroot/DATA/www/firstdomain
zfs set mountpoint=/iocage/jails/<bignum>/root/usr/local/www/firstdomain zroot/DATA/www/firstdomain
Where the data located in firstdomain directory reside? Does it leave insite the FreeBSD host or the jail?
Also if someone managed to hack the site.. and the webroot is firstdomain, can they get out of dataset and reach the host file?

Thank you
 
getopt said:
You most probably did not zpool create within a jail, aren't you?
Click to expand...
Sorry getopt I am not following you.. zfs create zroot/DATA/www/ was ran from the host as you cannot create create them from the jails.
So I guess from the reference to zpool(8) that the data reside on the FreeBSD host.

can the mount point be a security risk to the host?
 
fred974 said:
can user from the jail, excape the jail via the mount point?
Click to expand...

If they could the whole jail mechanism would be useless. These things were thought out very thoroughly when jails were designed, one of the main things was to plug some known holes that existed in the older technique, chroot(8), that under certain circumstances did allow a user to escape the chroot environment.
 
There's a jail(8) option that controls the information a jailed process can get from the mountpoint/filesystem the jail is rooted at:

Code: 
enforce_statfs
         This determines what information processes    in a jail are able to
         get about mount points.  It affects the behaviour of the follow-
         ing syscalls: statfs(2), fstatfs(2), getfsstat(2),    and
         fhstatfs(2) (as well as similar compatibility syscalls).  When
         set to 0, all mount points    are available without any restric-
         tions.  When set to 1, only mount points below the    jail's chroot
         directory are visible.  In    addition to that, the path to the
         jail's chroot directory is    removed    from the front of their    path-
         names.  When set to 2 (default), above syscalls can operate only
         on    a mount-point where the    jail's chroot directory    is located.
 
OK, I copied that into french transaltion and it make more sense:)
So because default is set to 2, nobody get out :)
 
fulano said:
There are no known ways to escape a jail.
Click to expand...

I love these kind of sentences. Why? Because they challenge some thoughts.

fulano did not say "I do not know ..." but instead said "there are no known ..." thus this is an assertion.

Assertions are in first line subject to belief. In IT we cope with this by trusting or refusing to do so.

Up to now we know about these historical security advisories:
2004-02-25 FreeBSD-SA-04:03.jail
2007-01-11 FreeBSD-SA-07:01.jail
2010-05-27 FreeBSD-SA-10:04.jail

So when you patched on 2004-02-25 or after 2007-01-11 were there ways to escape a jail? But before these dates a knowledge existed with some people. These dates are snapshots in regard to a community which shares it's knowledge about vulnerabilities with the public. But beyond this great community there exist markets where zero day exploits can be bought, while some exploits are still kept secret for some interest.

Now why do I spend my time writing this? I'm doing this because sentences like "all swans are white" appear in every day's life. But when you rely on them in a given situation, you might get bitten.
 
getopt said:
fulano did not say "I do not know ..." but instead said "there are no known ..." thus this is an assertion.
Click to expand...
It's the old adage, absence of evidence is not the same as evidence of absence ;)


fred974 said:
So because default is set to 2, nobody get out :)
Click to expand...
No, that has nothing to do with it. It simply means you can't 'see' the mountpoint with commands like mount(8) or du(1). But it's mounted and it is accessible, it just won't show up with those commands.
 
fred974 said:
For MySQL I created
Code: 
zfs create zroot/DATA
zfs set mountpoint=none zroot/DATA
zfs create -o recordsize=8k zroot/DATA/mysql
zfs create -o recordsize=128k -o primarycache=metadata zroot/DATA/mysql/mysql-innodb-logs
zfs create -o recordsize=16k -o primarycache=metadata zroot/DATA/mysql/mysql-innodb
Click to expand...

Sorry for the bump but I was looking for a "better way" of creating datasets exclusively for SQL hosting. What would those options (recordsizes and metadatas) bring as better to SQL, rather than the default ones?

Why are they better for SQL server/data?
 
You must log in or register to reply here.
Back
Top