Wildcard's questions

I have puppet code which automatically installs ifupdown2 on newly provisioned physical servers (along with all other new host configuration). (This is Debian 11 Bullseye.)

However, nearly all of the configuration fails, that's applied after this package is installed, because networking goes down on installation of ifupdown2, and so files can't be downloaded from the puppet server or from apt repos, etc.

Not only that, but Puppet can't self-recover from this. The box has to be handled out of band (i.e. console, ipmi, etc.) to either ifup -a or just reboot so networking will come back up.

I found this is a known issue for ifupdown2 installation: https://www.mail-archive.com/[email protected]/msg1703008.html

The recommendation there is:

For provisioning systems like ansible, puppet etc., I recommend that you set it up to push a script to the node that basically executes the equivalent of "apt-get install ifupdown2 && systemctl restart networking" using nohup or something else to make it not fail if the network itself is down.

My current relevant puppet stanza is just:

    package { "ifupdown2":
      ensure => 'latest',
    }

How should I fix this so the rest of the puppet config will apply correctly, i.e. so that networking will come up as part of applying that one resource?

This is with Puppet 5.5.22 and Foreman 1.22.0-develop. I know this is an outdated Foreman and Puppet installation but until I replace them with new versions (a soon upcoming project) they are what I must deal with.

# puppet agent -tv
Notice: Local environment: 'production' doesn't match server specified node environment 'development', switching agent to 'development'.
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Notice: Local environment: 'development' doesn't match server specified environment 'test', restarting agent run with environment 'test'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for servername.example.com
Info: Applying configuration version '1694623566'
Notice: Applied catalog in 12.93 seconds

I understand that the original local environment 'production' can come either from /etc/puppet/puppet.conf or is the default if no environment specified in that file. In this case it's the latter (no environment specified locally).

The node environment 'development' was set for this host in Foreman (the ENC or external node classifier for this Puppet installation) and is the desired correct environment assignment.

The environment 'test' is the environment that Foreman is setting, broadly and generally, for all of our hosts at this time and is the environment that this particular host was on before I changed it through the Foreman UI to be 'development.' (In other words, 'test' is actually our production environment; the environment called 'production' is not in use at this time.)

I tried consulting the Foreman documentation and didn't find anything about the underpinnings of how environment assignments work; the documentation just amounted to a tour of the UI which is not helpful for troubleshooting.

Likely related, there is another oddity here in that servername.example.com appears twice in Foreman's UI.

If I try to edit the environment for either entry by clicking the "Edit" button, when I then click "Submit" I get "has already been taken" showing in red next to the "Name" field as though I were trying to create a new host entry.

However if I instead select the host with the checkbox to the left from the list view and then go to the top and choose "Select Action" -> "Change Environment", then it appears to work. Both the entries then show "development" in the UI. But the next Puppet run on servername will produce the output shown at the top of this post, and then after that refreshing the Foreman UI will again show one entry with "development" and one entry with "test."

What could be causing this? How can I assign hosts to environments and have it stick?

I'm running Lucee Server, a cold fusion server engine that in my case runs on Tomcat, on Apache.

I'm looking into hardening it in various ways, and I'm running into a question about the SSH tunneling approach described here: https://docs.lucee.org/guides/deploying-lucee-server-apps/lockdown-guide.html#restricted-access-plus-ssh-tunnelling

The thing is, I don't think the description of how to do this ssh tunneling is accurate or complete. I spent a bunch of time looking at SSH documentation and also some other Stack Exchange questions (https://superuser.com/q/588591/504387, https://superuser.com/q/237977/504387) but still can't get SSH tunneling working as described in that guide or any other way.

Current setup, I have lucee running on server.example.com listening on port 8888. Apache running on the same server is listening on port 443 and is configured to proxy all requests to 127.0.0.1 on port 8888 (i.e. forward them to lucee). But it's configured to deny requests to /lucee as described in the above documentation.

This means the Lucee admin console can only be accessed directly at port 8888, not via port 443. Firewall rules (iptables) are set to allow incoming traffic on port 8888 only from the company internal network, so that we can access the lucee console but the outside world cannot.

This may be fine, but I was trying to see if I could make the tunneling approach work as described. If tunneling could work, we could ditch the iptables allow rule and just block port 8888 completely (except on loopback), or just reconfigure lucee to ONLY bind to 127.0.0.1.

SSH is on a nonstandard port on server.example.com, let's pretend it's 3300.

What I want to do is run an SSH command on my laptop that will:

1. Use my existing ssh configuration and key to connect me to server.example.com (where sshd is listening on port 3300),
2. Bind to whatever port on localhost on my laptop, let's say 60001,
3. FROM the remote end at server.example.com, connect in turn to 127.0.0.1:8888 so traffic can be passed to lucee.

The end result should be that I can access http://127.0.0.1:60001/lucee/admin/server.cfm on my laptop and it will be received by lucee running on server.example.com and listening to port 8888 bound to 127.0.0.1 on that server.

How can I do this?

I know how to get the DN from the command line:

adquery user -D "$(hostname -s)"

However, I want to get the DN into an adedit script. If I can select_object {DN here}, then I can do the other things I need to do.

I just don't know how to get the DN directly in adedit.

According to the adquery man page (part of the Centrify Suite):

The adquery command is provided for backward compatibility to enable you to query Active Directory for information about users and groups from the command line on a Centrify-managed computer. You can use this command to query information for classic or hierarchical zones. In most cases, however, you should use adedit commands or scripts to query Active Directory for information in hierarchical zones.

However, there is no clear documentation I can find on how to translate adquery commands into native calls within adedit.

For example:

adquery user `hostname -s` --dump

This gives a list of all the raw attributes and values for the user that is the computer I'm running the command on. Using the --attribute flag, I can return just one attribute.

With adedit, after I've run select_object THE_DN, I can get other fields such as "description" by running get_object_field description. But, how to get the DN in the first place?

I've found the adedit programmer's guide, but can't find what I need in there despite extensive digging and experimentation.

Until I get a better approach, I am running:

adedit myscript "$(adquery user -D "$(hostname -s)")"

And then in the script:

if { $argc != 1 } {
  puts "format: $argv0 hostDN"
  exit 1
}

set the_dn [lindex $argv 0]

bind ... (credentials here)

select_object $the_dn

(Note: adedit is built on Tcl, so I've tagged this question Tcl as well as Active Directory. I don't have the reputation to create a Centrify tag.)