Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

BSD Cafe Billboard

N

nibori

@nibori
About
Posts
4
Topics
3
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • Tell about your best practices setting up a FreeBSD server
    N nibori

    There are many guides on setting up / hardening your server. Books, the manual, all good resources.

    I don't expect you to reproduce full books worth of content, or dump a lifetime of experience into a single post - but certainly anything you think important, under-covered or underappreciated in the "usual" resources, would be keen to know!

    To start, if I had to call out one best practice that stuck on me, it would be keeping the base system minimal, and putting services into jails (or, maybe daemonless going forward).

    FreeBSD setup hardening best-practices freebsd

  • An outsider's perspective on Podman/Docker containers vs jails
    N nibori

    Dear Café,

    In the nice bar mood setting, I thought I would share my impressions when pondering changing from Linux-originated container technology to FreeBSD jails. Please treat what I say here as you would treat some fellow meandering about his stories about his great errands - with a bit of interest, and a bit of reservation. In the end, you can never know how much of it is true or accurate, and how much of it is just made up or self-believed misconception.

    Reading up forums and hearing people, Container vs Jails seems to be about technical merits or security stance. Won't comment on those (I believe in the wake of modern discoveries these would need a lot deeper and nuanced analysis, than could be hand-waved away as easily done), but highlight a more selfish divide: portability and reproducibility of configuration.

    You see, I worked at places, and often heard "cattle not pets". Means you should not grow to like and treat a given system with utmost devotion (like you would a pet), but rather treat it as dispensable, replaceable (like... ok.. maybe the anglophone metaphor breaks down a bit, since you would still not be that crude to cattle, but anyway). In retrospect, one driving force behind this might be the many kinds of Linux systems - each shipping a different version of (spare me for uttering the name) systemd, having slightly different conventions of location or structuring of configuration files, naming and packaging utilities up slightly differently etc. So you incline not to grow too attached with a flavor of Linux, and try to abstract.

    (Truth be told, the luxury of abstraction is more the privilege of the application developers.. the more you are an infra developer or sysadmin kind, the less you can distance yourself from the pits of configuration and system specifics)

    Thus, Containers (packaging up a userland into a neat layered tarball) are used not because we (app developers with some sysadmin blood flowing in the veins too) couldn't configure a system to run some service directly. It is because we don't want to, because the next day on an other distro it would work and break very slightly differently. We don't want to care, we want uniformity.

    So we package the userland, and expose some minimal surface to configure (ah, the diversification there too.. ENV vars, command-line flags... or, if you really need it, mounting some specific config files into the running container), and thus run our little services.

    Jails... a very interesting topic. Giving you all the isolation you want, yet not sparing from the usual burdens of configuring. But, this is where the uniformity of FreeBSD might be a savior. If you get those etc files right once, you can keep reusing them forever (hey, anyway, I said mounting some config files into a container every now and then fine, so setting up some config files to a jail must fly as well).

    (Just between us, there's still a gap between "can run this service with passing some flags to the container config" and "need to create jail, install some packages inside, copy some config files inside". For a linux app dev, the former sounds reproducible/minimal. The latter gives an Ansible vibe, which is tolerable, but never raises fond memories. Aside, with Podman coming to FreeBSD, maybe this gap would close as well)

    Then there's the lingering self-doubt. If it is a jail, will I be able to resist to apply a one-off fix inside, that I forget to record in whatever manual or automation if I want to set a jail up the next time? The userland of running containers is immutable - well there's the mutable overlay, but when you kill and restart the service, you expect it to just run with only the immutable layers reconstructed.

    An other factor might be backups. Don't think it is standard expectation that in event of failure, there would be meaningful backups of the running system state. Not of the system you treat as cattle, anyway. So your best bet is to have all these minimal specifications of what containers you run with what parameters, and better they work if you need to spin them up on a quickly provisioned new node!

    But, if you have a great backup culture, and can restore jail contents quickly and at will (and can bridge that time over somehow for your service), then maaaaybe you don't need to have all cattle. Maybe you can have pets. Maybe it is ok to fix things in-jail, since you have an immutable historic backup record you can compare against.

    The promise of FreeBSD with jails is that we can again be the sysadmins and small kings of our own kingdoms. The reality of running services as Containers is the demanding expectation to herd a cattle without mercy. And here we are, torn between words.

    Thank you for your attention, now let's get an other beer.

    FreeBSD

  • The probably underwhelming diary of a new OpenBSD user
    N nibori

    Without much structure or thought, might serve as a record, for me or others.

    Installer: from usb stick, the install experience is nice! Just hardcore enough that I feel the system assumes I have some idea about computery things, but not brew to the point of confusion. For example, at one point it asks which install target, and prompts "sd0 sr1 ?" (or such.. maybe a b... don't take my word). On pressing ? it gives a brief oneliner of each device. Just enough to make the choice, just brew enough I'm amazed.

    At one point install prints "relinking to make unique kernel". Wow.

    Booting: after entering passphrase, it gives me "boot>". Okay... Boot you say? So I type "boot", half-expecting based on past grub experience I will see some arcane message. But instead it actually boots! Neat.

    On login to system, there's a welcome mail with instructions. The man pages indeed work! Could connect to wifi with just using ifconfig. Well, needed fw_update first to get the wifi driver. Where are the logs though? Linux would spray dmesg with link state foo bar, or wpa auth so and so.. here I didn't notice similar.

    (Sidenote: the feeling when you adjust ifconfig and route, it still doesn't work, and it turns out be a flaky cable... flood ping for the rescue)

    Looking at the filesystem. Looks clean! Hm, no /proc, /sys? Where do I get some stats about the battery? Will discover later.

    Consoles... multiple consoles anyone? Alt+F2 doesn't work. Maybe it is the key mapping, or maybe it is not supposed to have multiple consoles by default?

    Hm, what could be the equivalent of "loadkeys"? Well, can work with en layout for now.

    startx gives me xterm and xclock, with a blue-red colorscheme. Wicked.

    pkg_add works. pkg_info executed plainly gives a list of explicitly installed packages!

    To be continued, eventually...

    OpenBSD

  • Tell about your best practices setting up a FreeBSD server
    N nibori

    Sidenote: some of the search results coming up

    • https://docs.freebsd.org/en/books/handbook/security/
    • https://github.com/wravoc/harden-freebsd (comments at https://forums.freebsd.org/threads/my-freebsd-hardening-script.89523/)
    • https://www.freebsdsoftware.org/blog/hardening-freebsd-server/
    • https://vez.mrsk.me/freebsd-defaults
    • https://hardenedbsd.org/content/about
    FreeBSD setup hardening best-practices freebsd
  • Login

  • Don't have an account? Register

  • Login or register to search.
Powered by NodeBB Contributors
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups