Hank Gay's questions

I'm standing up a new Nagios server, and I have run into a bit of a snag. Our existing server is running FreeBSD 11 w/ Nagios 4.3.4 and nrpe2. It can communicate w/ the nrpe2 daemons on our various servers (Ubuntu Xenial boxes, for the most part) as well as a few FreeBSD boxes running nrpe3. The new Nagios server, however, cannot talk to the nrpe2 clients (it can reach the nrpe3 clients). The error I get is:

CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with <insert_private_ip_here>: 1

I've tried adding in debug output on the client machines, but that's still the only error message I'm getting. From what I can see, nrpe3 and nrpe2 are supposed to be able to communicate, so my guess is this has something to do with different SSL/TLS versions and/or enabled ciphers, but I have been unable to find any documentation confirming that guess, or listing which ones I should enable to enable the two versions to communicate.

What is the actual problem here, and how do I fix it?

I know most of the general advice: "turn off unnecessary services", "no really, turn off unnecessary services", "least privilege", etc. I've also seen a few guides and/or tools, e.g., Bastille, for hardening Linux boxes, but nothing that seems tailored to NetBSD.

Assume for the sake of this list that I've already made sure root doesn't have SSH access, but that I haven't installed any server software.

What are your first steps for securing a new NetBSD box?

UPDATE: To be clear, I'm looking for specific steps. I'm entirely self-taught when it comes to server admin, but I feel I have a decent grasp of the general principles. I'm looking for details for two reasons:

1. To see if there is anything NetBSD-specific that I've overlooked.
2. To see if other people have better methods for putting the general principles into practice.

Thanks.

I'm rapidly becoming a FreeBSD convert (from Linux). I'm also intrigued by djb's software. Is there a good guide to replacing the standard set of FreeBSD utilities with their djb equivalent? It would be swell if that also happened to leverage ports, but I'm willing to do it manually if that's the way to do it.

Thanks.

Is there a pre-existing startup script for supervisord on FreeBSD? If not, is there a good guide for writing rc.d scripts for FreeBSD? I'm pretty new to the platform.

Thanks.

UPDATE:

I now have the following in /usr/local/etc/rc.d/supervisord, but it doesn't seem to be working. I'm not seeing anything in the startup scroll related to supervisord.

#!/bin/sh

# PROVIDE: supervisord
# REQUIRE: LOGIN
# KEYWORD: shutdown

. /etc/rc.subr

name="supervisord"
rcvar=`set_rcvar`
load_rc_config "$name"

command="/usr/local/bin/${name}"
command_args="-c /usr/local/etc/supervisord.conf"

supervisord_enable=${supervisord_enable-"NO"}
supervisord_pidfile=${supervisord_pidfile-"/var/run/supervisord.pid"}

pidfile="${supervisord_pidfile}"

run_rc_command "$1"

If so, how?

This is related to Question 43805. If the repo is properly chmoded but outside the document root directory tree, Apache complains that it can't access the format file in the root of the repo. If the repo is somewhere in the document root directory tree, everything works.

I am attempting to add read-only HTTP access to an existing svn repository while still allowing write access via svn+ssh.

I have installed Apache, mod_dav_svn, etc. and pointed Apache at the svn repository, but when I attempt to access the repo via HTTP, I get the following error:

Could not open the requested SVN filesystem

When I look at the error_log for Apache, I see that it can't open the format file in my repository. That file is readable by everyone but writable by no one, and it seems to work for svn+ssh access. How can I resolve the problem for Apache without impacting svn+ssh access for the developers?

Thanks.

UPDATE: It appears this isn't restricted to the existing repo. I just created a brand-new test repo, ran chown -R apache:apache on it, and I still get the same problem. I've verified that the apache user does have execute permissions on every directory on the way to format and read permissions on format. However, if I create a test repo somewhere in the directory tree Apache is using as the document root, things work OK. Is Apache chrooted (or similar) on CentOS 5.3? If so, can I circumvent that? Thanks again.

I'm trying to follow the steps from the MigrationGuide (modified to reflect the fact I'm dealing with non-current versions) to migrate from RHEL 5.1 to CentOS 5.1. I used the following commands:

# rpm -e --nodeps redhat-release-notes redhat-release yum-rhn-plugin redhat-logos
# rpm -ivh http://vault.centos.org/5.1/os/x86_64/CentOS/centos-release-5-1.0.el5.centos.1.x86_64.rpm http://vault.centos.org/5.1/os/x86_64/CentOS/centos-release-notes-5.1.0-2.x86_64.rpm
# yum update

This fails on the yum update step with an error claiming there's a conflict between e2fsprogs and the kernel. I've included a more detailed error below.

# yum -d7 upgrade kernel
Loading "installonlyn" plugin
Running "config" handler for "installonlyn" plugin
Yum Version: 3.0.1
COMMAND: yum -d7 
Installroot: /
Ext Commands:

   kernel
Setting up Upgrade Process
Setting up repositories
Reading repository metadata in from local files
Setting up Package Sacks
Reading Local RPMDB
Building updates object
Resolving Dependencies
1248192166.57
--> Populating transaction set with selected packages. Please wait.
Member: kernel.x86_64 0-2.6.18-128.2.1.el5 - u
kernel - 2.6.18-128.2.1.el5.x86_64 converted to install
Adding Package kernel - 2.6.18-128.2.1.el5.x86_64 in mode i
---> Package kernel.x86_64 0:2.6.18-128.2.1.el5 set to be installed
--> Running transaction check
# of Deps = 1

Dep Number: 1/1

--> Processing Conflict: kernel conflicts e2fsprogs < 1.37-4
TSINFO: Updating e2fsprogs - 1.39-20.el5.x86_64 to resolve conflict.
miss = 0
conf = 0
CheckDeps = 1
--> Restarting Dependency Resolution with new changes.
---> Loop Number: 2
Restarting Loop
--> Populating transaction set with selected packages. Please wait.
Member: kernel.x86_64 0-2.6.18-128.2.1.el5 - i
Member: e2fsprogs.x86_64 0-1.39-20.el5 - u
Adding Package e2fsprogs - 1.39-20.el5.x86_64 in mode u
---> Package e2fsprogs.x86_64 0:1.39-20.el5 set to be updated
--> Running transaction check
# of Deps = 3

Dep Number: 1/3

--> Processing Conflict: kernel conflicts e2fsprogs < 1.37-4
Error: No Package Matching kernel.x86_64

I've found myself in charge of installing some software on an old server running RHEL 5. Unfortunately, since it's just a development server now, it no longer rates a license. I'd like to continue using yum for dependency resolution, etc. My first thought was to just point yum at some CentOS repos, but some googling turned up this instead: migrating from WBEL 3 to CentOS 3. Is this sort of approach my best bet? If so, how much of the migration process is different for my scenario compared to the one in those instructions?