From owner-freebsd-questions@freebsd.org Tue Jun 20 15:34:30 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 810B7D9B2F3 for ; Tue, 20 Jun 2017 15:34:30 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 052032DF9 for ; Tue, 20 Jun 2017 15:34:29 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from zero-gravitas.local (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 839E1C275 for ; Tue, 20 Jun 2017 15:34:21 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/839E1C275; dkim=none; dkim-atps=neutral Subject: Re: New User, new server To: freebsd-questions@freebsd.org References: <800e15b2-d7f5-d339-bd77-862e9d0cab5b@ludikovsky.name> From: Matthew Seaman Message-ID: Date: Tue, 20 Jun 2017 16:34:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <800e15b2-d7f5-d339-bd77-862e9d0cab5b@ludikovsky.name> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aeJXQpvmA31K04hfmd2nRSO0VTX2X6V0h" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 15:34:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aeJXQpvmA31K04hfmd2nRSO0VTX2X6V0h Content-Type: multipart/mixed; boundary="dSTSfKnSXTjlAW6IvBOw0Xdp3STWQw9QO"; protected-headers="v1" From: Matthew Seaman To: freebsd-questions@freebsd.org Message-ID: Subject: Re: New User, new server References: <800e15b2-d7f5-d339-bd77-862e9d0cab5b@ludikovsky.name> In-Reply-To: <800e15b2-d7f5-d339-bd77-862e9d0cab5b@ludikovsky.name> --dSTSfKnSXTjlAW6IvBOw0Xdp3STWQw9QO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017/06/20 15:33, Peter Ludikovsky wrote: > Hello, >=20 > I recently acquired a former office tower to replace my old home server= > (Debian 8), itself an even older office tower. As it's my primary > storage location for images and documents I want something stable, and = I > want to try something besides Linux, so I'm going for FreeBSD > 11-RELEASE. Which brings a few questions: >=20 > 1) The new machine comes with a 128G SSD, in addition to the 2 4T HDDs > from the older server. I'd like to set up ZFS root, with a slice of the= > SSD as ZIL and L2ARC, and the root mirrored across the SSD and the 2 > HDDs. Does this make sense, and if so what would be the ideal slice > layout? Or should I just use the whole SSD as ZIL/L2ARC? Use the 2 4T HDDs for your main zdev, and keep the SSD for ZIL/ARC separately. zpools work better if all of the storage devices are about the same size and performance level. Given you're going to mirror the two 4T HDDs, be aware that having just one physical device for your separate logs will reintroduce a single point of failure. Even though a separate log device is not /required/, and you can add and remove log devices on the fly, your system will still crash'n'burn if the log device dies unexpectedly on you. Better to have mirrored logs if you can swing another SSD. Oh, and with a SLOG device you generally don't need to allocate a huge amount of space for all the different types of log. Given the throughput on the SSD, it's a good idea to run it 'undercommitted' (with plenty of unallocated space) as this will give you extended life on the device. Because of the wear-leveling, all of the memory cells on the device will eventually be used, so by restricting the size of the allocated areas, you effectively give yourself access to a lot more "spare" memory cells than the device would give you as standard. > 1.1) Can I start this setup with just the SSD an one HDD, as to keep th= e > old server alive until everything is migrated? Yes. > 2) Moving data from the old machine. Can I run zfs send/receive to get > the ZFS on Linux datasets onto FreeBSD, or do I need to (r)sync? That depends on the relative capabilities of the ZFS setup on each end of the zfs send/receive chain. Generally you can send from an older ZFS to a newer one, but not vice versa. It's easy to test though -- just create a very small ZFS and try sending that to the other server. > 3) Firewalling: PF, IPFW, or IPFilter? The machine will be behind an IS= P > provided router, but I'm paranoid enough to want an additional firewall= > on that machine, and one that plays nice with fail2ban at that. PF has a much nicer (IMHO) configuration interface, but IPFW is higher performance (although I doubt you're going to notice any difference unless you'll be generating traffic at 1Gb/s or above for extended periods.) ipfilter is there for compatibility with other machines that are running legacy ipfilter setups. Not recommended for a new install. > 4) As far as I understand it the host plays gateway for jails. Does tha= t > mean that any firewalling is done there too? If so, is any special > configuration required besides enabling IP forwarding? (NAT, =E2=80=A6)= This depends on the type of jail. The traditional way, host and jails share a single IP stack, and the host provides firewall services for all of the jails. There is a newer way of running jails -- keyword here is 'VIMAGE' (see: https://wiki.freebsd.org/VIMAGE) -- where each jail gets a separate network stack and can run its own firewall. This entails use of something like an epair(4) interface, where one end gets passed to the jail, and the other gets bridged together with the spare epairs from other jails etc. to make a virtual switch inside the host machine. VIMAGE is cool, and it has had a lot of work into making it run much more smoothly nowadays, but if you've never used jails at all before now, I'd advise you to start with just the regular style of jail. I'd also suggest looking into a jail management system like iocage. > 5) Currently all services on the machine run together. With FreeBSD I'd= > like to jail them. Is there an easy way to convert, or will I be > creating jails for the services & shovel the data over as if it's a > fresh install? You can probably copy over config files, data etc. as the basis of the config in your new jails, but they will need manual editing to set the correct IP numbers and so forth. As far as I know, there isn't a generic and automated way to do that. On the other hand, a host with a bunch of jails can be managed very sweetly using something like ansible(1) -- everyone wants onto the devops bandwagon, eh? > Any pointers are appreciated. I'm in no hurry (old machine ain't dying > yet), and I'd rather do it slow & clean than fast & dirty. In that case, experiment. Try out a number of different scenarios on some throwaway test environments, then blow all that away and implement a 'for real' setup with the benefit of what you've learned in testing. Cheers, Matthew --dSTSfKnSXTjlAW6IvBOw0Xdp3STWQw9QO-- --aeJXQpvmA31K04hfmd2nRSO0VTX2X6V0h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJ8BAEBCgBmBQJZSUB8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnMoEQAJJDmsGke0POzWjkT02SVTOF AVvMZCWgfDFUNjROMvBW8L513DBBdAzGbKZKUKox+imLKfdDcoBQRpbABiofRPBu 34Q4KfHZlxPqsNYMazunKXcefKhmYpiIR1BFB1tNWTMP8yg5DdYJ5fXiOGIIcgQv Cg4dmerS3BfNbnuUpeF2tlRPkFxOLx5sDakQvAzXZk+SO/Ah48UF/S10CWdJNYyW 1geKoatxdCuCbFYQbLtyQOd6l1rUfPvPD4gtEje4nMQOsHXyFXXwHLJnaPT1LGOP RivZNawdalcUMVEoHWooJoQMhnz6oE7dt7MNGroRzjY1CG5dhSVPbHoTgA84L2ug GMOeukCKB9ZOQugv8eehzfl9FNJgSFK96VFi0e+uAQlmzO7ROStDBPG0aX1bCr0s +W+Ox2wCChfMuqWxuXrklmqHBOffUovogpqwMkDjibV869UgTcUrdkOrO4lJVBAf o0OeDDUQQynJZjEkzLpMaZ8Fe4nQ7n2nTICoZKxeeK3SOS2LioRKhbV8eEAhUz4/ DCOeKRfLRh7wMYgvSfdoDUgd+owvo4WvQxvgb1hKs+JBbm7X5Sxj4TrT6IrFrG4M +QFgq5XE6oC6ApAO+0JrxXmD3IZORKZ9NnyjoV0MMdnru4/suZbI9AO2VZDBoG+n pYWZywnSQ2dPiFqe+uU6 =KUWh -----END PGP SIGNATURE----- --aeJXQpvmA31K04hfmd2nRSO0VTX2X6V0h--