Have something to practice all those ideas on - not the production server, but something that is OK to mess up and delete.
Practice makes perfect :)

sko already mentioned it, if you're looking for ways to automate server installation and configuration you should invest time in learning chef/puppet/ansible. I learned Puppet a long time ago[*] and have grown to like it (it has a rather steep learning curve in my opinion). Ansible is a bit easier to get started with. It's also quite popular at the moment and many companies are migrating their Puppet infrastructure to Ansible. Learning Puppet or Ansible is also quite beneficial for other operating systems and will definitely increase your position on the unix admin job market. The "traditional" admin jobs are dying out, it's all devops and infrastucture-as-code nowadays.

[*] In the past 5-6 years I've been writing puppet code for most of my working days.
 
OP should just keep it simple. Have something to practice all those ideas on - not the production server, but something that is OK to mess up and delete. Once the results of practice are acceptable, take down some good notes, reproduce the steps for good measure, and only then touch the production stuff.
Thank You! Totally agree with this methodology.
 
But is any technical difference in both, or just endothermic style of code writing?
All roads lead to Rome. Something you will find out when dealing with developers and admins alike. If you ask 10 admins to write a script to do something you get 10 different scripts :)
 
Ok, I’ll do.

But is any technical difference in both, or just endothermic style of code writing?
What I am trying to tell you is, it doesn't matter. Stop reading the menus pasted outside restaurants; go inside one and eat! Find out from your own experience what works and what doesn't. in Patanjali's Yoga Sutra, the seventh Sutra says "right knowledge comes from direct experience, inference or testimony (of authority -- wise people or the scriptures)". Notice how direct experience is the first recommendation! And do not treat random people as authority! Even test what so called "authoritative" sources tell you!
 
I'd still want to see what's on offer, what looks appealing,
How do you know they are not lying to you or giving you the complete picture? My daughter, when she was 5, demanded a favorite dish of hers which was *not* on the menu of this particular upscale Chinese restaurant. The waiter said, no problem, it is his favorite too but they just didn't put on the menu! The direct experience can often be pleasantly surprising so don't bash it!
 
pkg install `cat pkglist.txt` will do it. You could incorporate that into your script. Also, portmaster `cat portlist.txt`: ports-mgmt/portmaster. I knew that the port category could also be included in a package list, but from reading this, there's more details that are useful.

` is on the keyboard below the Esc key; it's different from the regular single quote. This makes it so the output of the file from the cat command is directed into the main command.

I'm not sure if you meant something like this in your second post.

I would be interested in a script in sh(1), the basic Bourne shell.
 
How do you know they are not lying to you or giving you the complete picture? My daughter, when she was 5, demanded a favorite dish of hers which was *not* on the menu of this particular upscale Chinese restaurant. The waiter said, no problem, it is his favorite too but they just didn't put on the menu! The direct experience can often be pleasantly surprising so don't bash it!
Most places don't post the complete menu on the doorstep anyway. Just enough to grab you by the nose. ;) Software is like that, too. You read a little of the description, play with it a little, and if you like it, you go all in. But you gotta have a good idea of what you're getting into.
 
… In your pkg list file put category/package-name

Beware of doing so where, for example, there are flavours of a port.

Code:
% pkg info -x falk
falkon-22.04.1
% sudo pkg install --dry-run www/falkon
grahamperrin's password:
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        falkon-qtonly: 22.04.1 [FreeBSD]

Number of packages to be installed: 1

The process will require 11 MiB more space.
2 MiB to be downloaded.
%
  • I already have full-flavoured Falkon
  • I don't want the inferior flavour.
<https://www.freshports.org/www/falkon/#flavors>
 
Beware of doing so where, for example, there are flavours of a port.
I'm wondering about port category along with pkg origin for flavors for this. Could the desired flavor be selected this way?
This is going to pose a problem when the default Python version changes. Use the port origin in this case; pkg install net/py-speedtest-cli. Then it will always be installed, regardless of the Python version at that time.
The port is net/py-speedtest-cli, that's called the "origin" in FreeBSD's port/package lingo. Depending on the (default) version of Python the name of the resulting package is py${PYTHON_VERSION}-speedtest-cli. If the Python version changes to 3.9 for example the package would be named py39-speedtest-cli. See how that Python version is reflected in the package name? If you try to install py38-speedtest-cli it will fail, because the package is now called py39-speedtest-cli. If you run pkg install net/py-speedtest-cli, it will always be installed, regardless of what the (default) Python version happens to be.
It looks like pkg origin only works on packages which are installed. I tried it on a package I had installed, and it showed the origin. When I tried it on the above example, also based on the output of pkg search, it didn't work.

pkg search electrum; pkg origin py38-electrum
Code:
py38-electrum-4.2.1_1          Easy to use Bitcoin client
finance/electrum
I tried it on falkon-qtonly as well. pkg origin only worked for it after I installed it.
 
  • I already have full-flavoured Falkon
  • I don't want the inferior flavour.
I guess you'll need a more complicated script! Put flavored packages on lines by themselves?
$ cd /usr/ports/www/falkon
$ make package-name
falkon-22.04.1
$ make FLAVOR=qtonly package-name
falkon-qtonly-22.04.1

Ideally language version dependency would be done differently to allow for the simple version....
 
If you look at an existing server, to get a list of packages to install, look at the output from pkg prime-list, or pkg prime-origins. You don't want to install everything, you only want to install the packages you need. Dependencies can change over time and they will automatically be installed, so you don't need to install those yourself.
Extra one tough come to me: about quarterly vs latest.

There are always a lot of holy wars on any forums about “old but stable, with several bugs that I already have workaround
vs
latest with some improvement and new features, annoying bugs fixed and a few little new bugs”.

Life in IT always going speed up, developers always have a short time to fix bugs, and making new features. For a various of reasons (including SaaS, DevOps paradigm, sharing code platform like GitHub, Stackexchange, Stackoverflow, etc) that we not need to discuss here.

As a result we always constantly have software with some amount of bugs, so difference between “quarterly” and “latest” strategies for systems with big community and deployment base (like FreeBSD are) just become to nothing.

So, may be correcting the /usr/local/etc/pkg/repos/FreeBSD.conf as described

Change between `quarterly` and `latest` package set used by `pkg` tool in FreeBSD and

How to install the latest version of software in FreeBSD? would be also great?

 
How about with packages only, without make, building ports or port options?
This is what we starting at the first of this tread: automated script. To manually install what a You need, BUT all modifications of system config files (if they needed), You may doing yourself manually.
So this is “semi-automation”, and may be good for home users with a lot of free time to manual operations on one machine.

As next step the same script may be used in Ansible with addition to another scripts to doing needed modifications of system files/configs (like loader.conf, rc.conf, etc....) for each of installed packages.
So, in this case we have “fully automated” system.

P.S. Because this certain case is about installing on bare metal servers with numbers up to 200 (no virtual dynamically created), and we also be happy to use the same system to operate with active network applience, we not need complexity with a reactions on environment/inputs and IFTTT logic realization.
So in this certain case powerful orchestrate system like Chef, CFengine, Salt, StackSorm not needed.
 
How about with packages only, without make, building ports or port options?

Edit: in response to
This was already covered earlier by SirDice. There is no simple solution as for example python packages currently start with "py38-" and those packages will fail once python moves to version 3.9. May be you can use category/package-name and flavored package names and that would work -- except for the case where flavored packaged depend on a python version! For this more general case you need something more complicated, such as mapping from category/package-name to package-name-flavor by using make.
 
What I am trying to tell you is, it doesn't matter. Stop reading the menus pasted outside restaurants; go inside one and eat! Find out from your own experience what works and what doesn't. in Patanjali's Yoga Sutra, the seventh Sutra says "right knowledge comes from direct experience, inference or testimony (of authority -- wise people or the scriptures)". Notice how direct experience is the first recommendation! And do not treat random people as authority! Even test what so called "authoritative" sources tell you!
Hm... Some time ago I study in University and live in India in several different places. (This is as a background for this reply).

And I need to say: if You have a lot of time and have a fun from trying that, than trying that, no matter is this crashing system or not, - Your arguments are ok.

But a lot of technical forums nowadays exist to eliminate time and risks in everyday tech work. So, if the case are more or less trivial - better not loose time (both Yours and employer) and asking the peoples who was SPENDING A DECADES to be PRO.
 
I already got that, and already acknowledged that about using pkg origin.

I wanted to know if there was (or wasn't) a way to go with flavors regarding pkg and pkg origin without make.

@ bakul
 
And I need to say: if You have a lot of time and have a fun from trying that, than trying that, no matter is this crashing system or not, - Your arguments are ok.

But a lot of technical forums nowadays exist to eliminate time and risks in everyday tech work. So, if the case are more or less trivial - better not loose time (both Yours and employer) and asking the peoples who was SPENDING A DECADES to be PRO.
In my view, it is more a question of attitude than time. These forums may help you eliminate wasted time and reduce risks in the short term but won't give you a real insight or an ability to gain insight. It is like always eating junk food. It stops being satisfying after a while -- may be a long while! Now if you want to always remain a student (who has to ask) and never be a master then it doesn't matter. But if you want to master, wouldn't be better to practice on simple things first?!

Anyway, we are off on a tangent so I will stop here!
 
Practice makes perfect :)

sko already mentioned it, if you're looking for ways to automate server installation and configuration you should invest time in learning chef/puppet/ansible.
As I wrote before, in certainly this project:
1. we already have a lot of active network applience, mixed vendors, and only one common they have,- COM & SSH client inside. Only few have orchestrate client inside;
2. we already have some amount of bare metal servers, several well-known vendors, all of them have Integrated Management Module, so, even replacing crashed HDD and remote loading from mounted memstik possible;

I learned Puppet a long time ago[*] and have grown to like it (it has a rather steep learning curve in my opinion). Ansible is a bit easier to get started with. It's also quite popular at the moment and many companies are migrating their Puppet infrastructure to Ansible.
I definitely agree that Ansible are easiest orchestrate system from bunch of others.
And another BIG advantage (in addition to ability work with almost all active network applience, because only need SSH server built in applience) for SysAdmins are A LOT OF MODULES, EXAMPLES & DOCS.

Migrating most experienced SysAdmins, and services companies to Ansible based on several things:
- easy to start with (a lot of docs, examples, solutions);
- not locked to certain network appliances vendors (because needs of clients on appliances), this also impact TOC;
- easy to migrate from other old systems for experienced SysAdmins;
- for small companies with up to 200 bare metal servers units and up to 100 physical network appliances, with not so big and complexity infrastructure - Ansible would be Ideal;

If I wrong here, Il happy to read Your correction.
Learning Puppet or Ansible is also quite beneficial for other operating systems and will definitely increase your position on the unix admin job market.
Totally agree.

Little bit off-topic:
The "traditional" admin jobs are dying out, it's all devops and infrastucture-as-code nowadays.
I still thinking, the political and economical changes on the Far East, Europe and USA, increasing numbers of global outage, increasing numbers of hackers attacks on cloud infrastructures would pushing to situation where small/middle companies stepping back to using own facilities.

I do not remember authors name, in one book about high-loading reading calculation when after numbers of servers that company need to have come over 20, much better using own small infrastructure, from TCO, management, stability, security, enhancement point of view.

[*] In the past 5-6 years I've been writing puppet code for most of my working days.
Could You be so please to describe in short for what exactly type of solutions?
 
Some workplaces maintain sort of a 'template' image that they can quickly deploy. This may work for user-facing workstations, but servers are a different beast. You may have one box for email, another box hosting fileshares, yet another for firewall, and yet another for DNS. Yeah, they may have some common base (like all running same version of FreeBSD, like 13-RELEASE), and you want to have a good backup scenario so that you can recover quickly and be back up and running. Trouble is, that 'common base' is actually awfully minimal. FreeBSD already provides a bare-bones install image where you just need to turn on SSH and DHCP, but beyond that, an admin would need to maintain a backup copy of friggin' EVERYTHING. Automating the re-install procedure helps some, but it's still necessary to keep track of what goes where. This is partly why I kind of soured on Puppet and Ansible - Not only you gotta maintain the production stuff, you also gotta maintain a copy of it, which is frankly double the workload, even with those config managers helping out. 😩 Even if you manage to set it up to make it not quite double the workload, where do you store all that extra data?
 
where do you store all that extra data?
With ansible it's only textfiles. I put it (as almost all config-related stuff) in git-repositories hosted on a local server.
Our backups are zfs snpashot-based, so recovery is pretty straightforward, and with configurations in git-repos we always have another path for recovery if snapshots should somehow fail.
 
Back
Top