[04:51] <axisys> got a new server hp dl360 gen 9 with 12 SSD of 800G each. I need little bit of space for OS and rest will be for /home and /var and /var/log
[04:52] <axisys> any suggestion on partitioning? may be a raid 1 of two and raid 10 of the rest 10 in the hardware raid controller?
[04:52] <axisys> any suggestion SSD related?
[07:35] <lordievader> Good morning
[14:14] <drab> axisys: it really depends on what you're trying to achieve/workload
[14:14] <drab> and whether speed, data integrity/resiliancy etc are most important
[14:15] <drab> axisys: per yesterday's convo, if those are consumers ssds, overprovisioning would be a good thing to do, to help with perf long term
[14:16] <drab> and to make sure that trim is ran regularly
[14:17] <drab> regarding the raid controller, one thing that matters ime is whether you have more spare hw like that/and backups to restore in case the controller fails
[14:17] <drab> because most likely disks won't just work on a diff controller
[14:18] <qman__> highly dependent on the hardware
[14:18] <drab> yep
[14:18] <qman__> some manufacturers are pretty consistent with their structure and it'll work on most controllers by the same manufacturer, others not so much
[16:44] <ndboost> hey
[16:44] <ndboost> how can i run sftp on a seperate port and match only to users in group "sftp"?
[16:45] <ndboost> i get an error "Directive 'Subsystem' is not allowed within a Match block"
[16:53] <tomreyn> ndboost: use Match to restrict the set of options certain users or user groups have when connecting to the server. don't try to use it to provide those with elevated access. The 'Subsystem' directive is available on the global scope only.
[16:54] <ndboost> thx tomreyn this is what i ended up with but chroot aint working ... https://gist.github.com/mikedevita/2e545c5d0438ad0ed39c70db9021f856
[16:54] <tomreyn> sftp is a subsystem of ssh, i.e. users need to be able to connect to the ssh daemon using the ssh protocol first, then shift the protocol to sftp
[16:54] <ndboost> that makes sense
[16:55] <ndboost> looks liek bad perms
[16:57] <ndboost> bingo
[16:57] <ndboost> thx
[17:09] <tomreyn> ndboost: welcome, but have you now achieved to prevent that the sftp users (those in Group 'sftp') are no longer able to authenticate to port 22 and operate there without restrictions?
[17:09] <ndboost> i have 22 locked down
[17:10] <ndboost> what else would i need, i have Port 22 and Port 2222 in sshd_config, then that block i showed you
[17:10] <tomreyn> ok, i wonder how you locked down 22 then
[17:10] <ndboost> and sftp users are set to /bin/false as their shell, and are in sftp group
[17:10] <ndboost> just firewall
[17:11] <tomreyn> oh so sshd listens on 22 but the firewall prevents access to it form all or most source locations
[17:11] <tomreyn> i guess this works.
[17:11] <ndboost> yes
[17:11] <ndboost> i have a select few of IPs whitelisted
[17:11] <ndboost> for 22
[17:12] <ndboost> and all ipv4/6 on 2222
[17:12] <tomreyn> consider doing it the other way around if you want to do users a favor
[17:12] <tomreyn> but other than that, sounds good to me.
[17:13] <tomreyn> you might want to allow only public key authentication on the 'admin' port (where users can get a shell)
[17:13] <ndboost> yeah but then i get tons of hits on 22
[17:13] <ndboost> i only allow pubkey auth on ssh
[17:14] <ndboost> and the users are editing web docs n stuff, they should be competent enough to use 2222
[17:14] <tomreyn> totally not ;)
[17:14] <ndboost> lol
[17:14] <tomreyn> but your config sounds good to me.
[18:32] <patdk-l2> why would you use port 2222?
[18:33] <patdk-l2> I have a few friends that use port 222 or 2222 isntead of 22, to stop attacks
[18:33] <patdk-l2> their logs show just as many attempts as mine on port 22, in the same ip space
[20:11] <axisys> drab: well this server will be used a for tons of scripts .. mostly cpu and mem intensive..
[20:12] <axisys> based on the current build on the old server
[20:12] <axisys> drab: ^
[20:13] <axisys> so do I need to build a raid5/6 with many spares.. or just a raid1 (2 disks) and a raid10 (10 disks) will do?
[20:13] <axisys> I suppose running trim is a must since these are all SSDs and do I need a discard in fstab?
[20:14] <axisys> also found this https://wiki.debian.org/SSDOptimization .. and probably applies to ubuntu as well since it is made from debian?
[20:34] <drab> axisys: if the workload is mostly cpu/mem intensive I don
[20:35] <drab> 't see the benefits of a configuration that adds to io perf (raid10)
[20:35] <drab> since you don't need the extra perf I'd go for extra reliability and build a raid6
[20:35] <drab> with as many spares as you can afford, but I'd say one is plenty considering you
[20:35] <drab> 're already got 2 drives safety net
[20:36] <axisys> drab: good point
[20:36] <drab> at which point no need to split the raid1 on its own, just have one raid6 which makes the whole system much more resiliant
[20:36] <axisys> so a raid1 and a raid6 .. where raid1 will be just for OS?
[20:36] <axisys> ah.. :-)
[20:37] <drab> if you split your os can only rtake 1 disk failure, after which it's out
[20:37] <drab> if it's on on raid6 with a spare the whole thing can survive 3 disks
[20:37] <axisys> right
[20:37] <drab> which is a heck of a lot
[20:38] <axisys> as for swap.. I see not to use SSD for swap.. and I see current system (retired onces the new one built) swappiness is 0
[20:39] <axisys> but swap went up to about 2G in May when we had some network dependency broke. and restored since then.. but swap stayed at flat line 1.6G per our monitor
[20:40] <drab> there's a ton of arguments on using no swap on the webs, that swap is bad, blah blah blah, and it's true that swap is the killer, but ime it's saner to make a small swap partition and monitor it, treating any sign of swappiness as something to fix, rather than to avoid swap altogether "because your app should never swap"
[20:40] <axisys> so obviously swap not in use in normal situation.. so since SSD is a no no for swap.. may be use RAM for swap (tmpfs) ?
[20:41] <axisys> I have 64G ram on new one.. and old one has 32G ram and 80% in use in avg per monitor
[20:41] <drab> you could do that, even tho swap on ram is as much of a practical joke as it gets :P
[20:42] <drab> I don't necesasrily see why swap is a no no for SSD, especially knowing that it almost never happens
[20:42] <axisys> drab: right..
[20:42] <drab> I'd rather "throw away" 2GB of SSD than 2GB of ram on a mem intensive workload
[20:42] <axisys> I am not leaning to any direction.. discussing
[20:44] <axisys> I just did a swapoff -a && swapon -a on the old system since I have 20G ram available..
[20:45] <axisys> so I guess I can run that routinely
[20:45] <axisys> yes it does check if enough mem available before running the off/on.. with a script
[20:46] <axisys> .. if enough mem available to take over the used swap ..
[20:46] <axisys> drab: so you are saying use tmpfs on ssd ?
[20:46] <axisys> drab: just making sure I am following it correctly
[20:47] <axisys> oh one more question.. should I still use LVM in this scenario?
[20:48]  * axisys brb
[21:11]  * axisys back
[21:11] <axisys> do I still need lvm.. probably should ask in a different channel?
[21:52] <drab> axisys: I dind't understand the swapon/off comment. I'd just setup a small (4GB tops) swap partition on the SSDs, I don't see a problem with it and it seems better than using RAM (on a mem heavy workload machine)
[21:52] <drab> axisys: the main benefit of LVM is if you think you'll need to add/expand the storage
[21:52] <drab> if you're already using all the bays and you're likely to not be wanting to readjust partitions, then no need
[21:53] <drab> given that you want to use /var/ and /var/log, my guess would be you're better off to use it as things may change and you may need to reallocate space
[21:55] <drab> I've personally been bitten by this allocation issue enough times that I don't do it anymore, it's just one big partition except for home fileservers where /homes are indeed separate with quotas
[21:56] <drab> altho as I'm migrating everything to zfs that's also no longer something I have to worry about