For some of my jails that is how I run them too. Especially where I am being especially paranoid about security. We deal with the hands we are given. I wish I could run it as tight as that on all of my boxes, but the bosses I deal with do not want to waste money on upgrading old infrastructure but still get mad when it isn't running.
So fat jails are my best compromise. I agree. I would run jails with very few files. A static executable, a config file, a log file, and some pipes maybe. Don't need anything else, don't want anything else log file could be avoided with syslog, perhaps. Bonus points: chflag schg the exe and config files such that they cannot be altered Absent a good equivalent of Dockerfile, and compose features, I think this is doomed.
Longterm freebsd user btw. Nothing, except it doesn't look to be doing additive composition on top of images and it doesn't look familiar if you were targeting pods in a k8s style deployment. As a thing in itself? Its fine. Mainly, what's missing is helpful evidence of transition. Where's the BastilleBSD equivalent? How do I translate a Dockerfile to a Bastille script? I imagine the only thing wrong with it is that it's not nearly as well known as Docker.
Yes, mostly this. I think its targeting a different deployment model. I am not using it but the features sound fantastic, like a complete network for every jail without complex docker network interface solutions. Why dont they do a freebsd container runtime based on the jail semantics? They sound much more effective than the linux ones. Ok, the problem would be on how to run linux executables on freebsd. That problem is mostly solved.
Has been for years except for marginal sysctl calls unlikely in datacenter usage of Linux. Indeed, the first thing I thought when seeing this post was "I wonder how long the support for each FreeBSD release is". Still no match for the 10 year support CentOS users expected; IMO, 5 years is too short when installing out of cycle for instance, since the current stable This is much less of an issue with FreeBSD because the changes between releases are relatively small.
Some systems out there had 20 years worth of upgrades, from v4 all the way to v I wouldn't like to try that on Linux. You could probably get pretty close with Red Hat Linux 7. There might be a break somewhere that the upgrade doesn't work, but nothing sticks out in my mind. There is a great simple framework that can ease a lot the deployment and management of Jails called BastilleBSD.
You can install it with pkg install bastille. Also, it's Warren Lash who gets murdered, not Warner Losh MaxBarraclough 11 months ago prev next [—]. We'll publish the repository to github, gitlab and other places that are useful for our developers, users and contributors. However, if you have local changes, you can use the same tool to manage them as you use to pull in changes from FreeBSD. The simplest way to keep local changes especially trivial ones is to use git stash.
In its simplest form, you use git stash to record the changes which pushes them onto the stash stack. Most people use this to save changes before updating the tree as described above. They then use git stash apply to re-apply them to the tree. The stash is a stack of changes that can be examined with git stash list. This method is suitable when you have tiny tweaks to the tree. It is also integrated with the git pull command: just add — —autostash to the command line.
In subversion you need to merge the commit, and resolve the conflicts. Git also allows one to merge, along with the same problems. The git rebase command will basically replay all the commits relative to the parent branch at a newer location on that parent branch. This section will briefly cover how to do this, but will not cover all scenarios. Fortunately, with git rebase it usually is automatic. Once you enter that, you have your own local branch in the git repo.
Build and install it like you normally would, following the directions in the handbook. The following assumes you are starting with an unmodified tree. This will bring up an editor that lists all the commits in it.
This is typically what you are doing while updating the baseline though you also use the git rebase command to curate the commits you have in the branch. A pointer to a more complete treatment can be found at the end of this section. When you updated, you might see something like this:. You may want to first integrate the remote changes hint: e. Everything up-to-date. Last edited: Mar 2, ShelLuser said:. Git might not be the best of ideas for you, because you're not just getting the source code: you're downloading the entire repository backlog as well.
I have only skimmed your extensive guide and bookmarked it for later. I will just add that for the past few months I have been doing ports work with Git and committing with git svn dcommit.
This setup with Subversion managing the central repository and Git as the client is a decent workflow. If you want a central repository and better control over who gets to commit, review of the commit, and when, subversion is the best bet, especially for a lone developer or small outfit. Preetpal Active Member Reaction score: 30 Messages: Typically if you want access control, you split your repository this can be a good thing in many cases according into multiple repositories and give access to them selectively; you can even give readonly access you can achieve this with unix permissions if you allow to git usage over ssh.
There are also the git subtree commands which can make it easy to do this and get the history of files into a new repository. It also makes it easy to work across multiple machines I use it for my Emacs configuration; it also makes it trivial to test your code in different environments and makes it trivial to back up your code.
I would also recommend git because it's supported everywhere with official support even in Visual Studio. Preetpal What I'm trying to say is, if you want a central repository and the fewest number of people mucking around with it, subversion is the way to go. It's why FreeBSD and many other large projects use it. When you have small groups and lone developers sharing code in a more intimate way, git might be better to use.
Many thanks ShelLuser. I wanted to dive into that topic but allways felt like, phhee later maybe Well written! And considering the fact that we're talking about configuration files I'll briefly address this issue further below, but please keep in mind that the main focus of this tutorial is Git, and not so much system security.
Editorial I'm a command line nut. This is also where my nick is based on. As a result I spent hours on fine tuning my servers in my networks.
Yet sometimes it can happen that a specific configuration file gets so many changes over time that when looking back you wouldn't mind having another peek at that specific setup your had when for example " IRC server X was still part of the network ".
Of course that situation was 2 years ago and we don't keep backups for that long. But a VCS wouldn't have much of an issue with keeping a retention so long. Even 5 years shouldn't be too much of a problem, especially not for something fully dedicated to configuration files.
This has been on my Subversion todo list for years , but I never got around of actually doing it. Oct 27, Sep 7, Merge llvm-project Retire synchronous PPP kernel driver sppp 4.
Oct 22, Fix regression to verbose behavior introduced in 68bff4a. Nov 11, Nov 7, Oct 26, Nov 12, Remove history. Apr 13, Dec 19, Cirrus-CI: add a manually triggered arm64 task. Sep 14, Sep 21,
0コメント