Scott Pack's questions

I'm attempting to rebuild nwaller's sssd puppet module to be entirely LDAP based and to be a little cleaner. In it we have a resource defined for each authentication domain of the form

define sssd::domain ( 
  $domain = $name,
  $domain_description = '',
  $domain_type,
  $ldap_uri = 'ldap://example.com',
  $ldap_search_base = 'dc=example,dc=com',
  $simple_allow_groups,
....
)

This definition is then passed as a concat::fragment which fills out a template for building the final sssd.conf.

This all works great if I define the LDAP server within each node, as in:

nodes.pp

node "node1.systems.private" {
  include "puppet::client"
  class {
    'sssd':
      domains => [ 'LDAP' ],
      make_home_dir => true;
  }
  sssd::domain { 'LDAP':
    domain_type            => 'ldap',
    ldap_uri               => 'ldaps://ldap.site.com:636',
    ldap_search_base       => 'DC=site,DC=com',
    ldap_user_search_base  => 'OU=People,DC=site,DC=com',
    ldap_group_search_base => 'OU=Groups,DC=site,DC=com',
    ldap_default_bind_dn   => 'CN=bindaccount,OU=Service Accounts,OU=People,DC=site,DC=com',
    ldap_default_authtok   => 'soopersekretbindpw',
    simple_allow_groups    => ['SysAdmins','AppAdmins'],
  }
} 

What I would rather do is a much more hierarchical setup. Keep the sssd::domain definition as generic as possible, so I can maintain it as a module independent of our organization configurations. Define the LDAP server in a global config, and then within each node define which specific groups need access. So something more like:

modules/org/manifests/default.pp

class org::default {
  include "puppet::client"
  class {
    'sssd':
      domains => [ 'LDAP' ],
      make_home_dir => true;
  }
  sssd::domain { 'LDAP':
    domain_type            => 'ldap',
    ldap_uri               => 'ldaps://ldap.site.com:636',
    ldap_search_base       => 'DC=site,DC=com',
    ldap_user_search_base  => 'OU=People,DC=site,DC=com',
    ldap_group_search_base => 'OU=Groups,DC=site,DC=com',
    ldap_default_bind_dn   => 'CN=bindaccount,OU=Service Accounts,OU=People,DC=site,DC=com',
    ldap_default_authtok   => 'soopersekretbindpw',
  }
} 

nodes.pp

node "node1.systems.private" {
  include "org::default"

  sssd::domain { 'LDAP':
    simple_allow_groups    => ['SysAdmins','AppAdmins'],
  }
}

As expected this results in a duplicate declaration error when attempting to apply the definition. Is there a way to do this, selectively override parameters, or am I stuck with defining the authentication domain within the original definition and then overriding the authorization parameters within each node?

In my environment I have large numbers of systems with two interfaces, one is used for system access and management and the other is used for network monitoring. They both are in a link-up state but the monitoring port is TX blocked.

When using koan to reprovision these hosts against cobbler anaconda is inconsistent with which interface it names eth0, and since they both have link, I'm resorting to using ksdevice=<MAC>.

Ideally, I would like to use the built in cobbler variables to do this on the global level, so adding ksdevice=$interfaces['eth0']['mac_address'] to my kopts variable. However, cobbler doesn't seem to expand variables at this level.

Is there a way, built into cobbler, to populate system variables into the kopts field?

I am currently using snort-2.9.3.1 outputting unified2 log format and using barnyard2-1.9 to process the alerts and send them to both syslog and a database. In some cases I have multiple instances of snort running on the same host and would like to log them separately.

Is there a way to configure barnyard2 such that depending on the input file name it will take different actions.

Something like,

 [snortmain_unified.log]
 output alert_syslog: LOG_AUTH LOG_ALERT

 [snortsecondary_unified.log
 output alert_syslog: LOG_LOCAL1 LOG_ERR

I am hoping to avoid running multiple instances of barnyard2.

I am setting up a network monitoring system on RedHat 6 that will be receiving the packet feed from an inline tap. One of the functions of this device will be running Snort. Putting two NICs in the system for the tap is no problem, however since each instance of snortd can only operate on a single interface, monitoring the two interfaces separately will break a lot of the stream reassembly and flow tracking.

Since these NICs are receive only, is bonding the right way to aggregate these interfaces? The documentation almost seems to imply to me that, since I couldn't care less about transmitting packets, any mode will do what I need. Is this a valid assumption? Are there any oddities that I would need to watch out for if I do use bonding for this?

I am beginning to migrate my snort logging from alert_syslog to unified2 using barnyard2 as the processor. In some cases I have multiple instances of snort running on the same system. Since I have historically used syslog, it handled the multiple log input without problem, however with the switch to unified2 I am concerned about write collisions.

Currently, I am using the same snort.conf for each instance, and managing the separate instances in /etc/sysconfig/snort. Primarily for simplicity of configuration, and partially for development time on my part, I would like to be able to maintain the same snort.conf. Which, of course, means having all instances writing to the same unified log file.

I am concerned about write collisions as multiple processes attempt to write to the same file. Is this a known safe approach with snort? Are the write methods used by the unified2 output processor thread safe? Can anyone comment on the likelihood of total protonic reversal by doing this?

I have an application that generates report files in /opt/reports with files owned root:root at 0600. In an attempt to allow an external system to automagically process these reports I created a new service account user with group ‘report’, changed the group for /opt/reports to report and set the SUIG bit, then set the default ACL on the/opt/reports directory to include report group with 400 and mask with 400.

I notice that when I manually create a file the permissions are all set as expected, however when the application creates a file the defaults are not inherited.

[root@reports1 ~]# getfacl /opt/reports
getfacl: Removing leading '/' from absolute path names
# file: opt/reports
# owner: root
# group: report
user::rwx
group::r-x
other::r-x

[root@reports1 ~]# setfacl -R -d -n -m g:report:r,m::r /opt/reports/
[root@reports1 ~]# getfacl /opt/reports
getfacl: Removing leading '/' from absolute path names
# file: opt/reports
# owner: root
# group: report
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x              #effective:r--
default:group:report:r--
default:mask::r--
default:other::r-x

Creating the file manually seems to work ok

[root@reports1 ~]# echo "This is a test file" > /opt/reports/testfile.txt
[root@reports1 ~]# ls -l /opt/nessus_reports/testfile.txt
-rw-r--r--+ 1 root report 20 Apr 24 11:16 /opt/reports/testfile.txt
[root@reports1 ~]# getfacl /opt/reports/testfile.txt
getfacl: Removing leading '/' from absolute path names
# file: opt/reports/testfile.txt
# owner: root
# group: report
user::rw-
group::r-x                      #effective:r--
group:report:r--
mask::r--
other::r--

When generating a report with the application, however, the mask does propagate out to the new file

[root@reports1 ~]# ls -l /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
-rw-------+ 1 root report 125952 Apr 24 11:18 /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
[root@reports1 ~]# getfacl /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
getfacl: Removing leading '/' from absolute path names
# file: opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
# owner: root
# group: report
user::rw-
group::r-x                      #effective:---
group:report:r--                #effective:---
mask::---
other::---

Is this expected behavior, and I am simply misunderstanding the terminology involved? Did I miss a flag or option somewhere, am I approaching it from the wrong direction entirely?

I'm in a situation where, for ease of management reasons, I would like to use the same config file template for two classes. I only expect a small section of the config file to be different between the two, and since I expect both classes to be included for most nodes, I would like to have a simple conditional to determine which class is including the file.

As an example, let's assume both sensor and snuffler are included in the same node. I would like the template to look something like this

<% if scope.name == "sensor" %>
 include sensor/file1
 include sensor/file2
<% else %>
 include snuffler/file1
 include snuffler/file2
<% end %>

Is this possible directly or do I need to fall back to something like defining variables in the class definitions?

Using snort version 2.8.6, I am attempting to collect application performance stats such as

• Number of packets not processed due to application overload
• Percentage of time in processing layers (preprocessor, reassembly, pattern matching, etc)
• Number of packets processed
• etc

I am currently using perfmonitor preprocessor to dump performance stats, and graphing some of these values through SNMP calls. The documentation on this preprocessor is fairly limited and doesn't do a good job of explaining what the fields actually mean, or what time frame the figures are calculated over.

To get those kinds of performance metrics, what fields should I be looking at and how are those fields measured?

With software versions puppet-server 0.25.5 and puppet-dashboard 1.0.4, I have a fully functional puppet-dashboard instance complete with autoregistration of new check in reports. However, after enabling SSL on the vhost report auto-registration no longer occurs. I have verified that, from a user perspective the site otherwise functions correctly.

I have changed the PORT definition in my puppet_dashboard.rb file, and am not receiving any logs showing failed connections,etc.

Can anyone provide guidance on how best to debug, or fix this?

Instead of continually writing my own modules to convert systems into puppet management, I would prefer to leverage the community as much as possible. So far I have come across two sites that compile modules for distribution, Puppet Wiki and Puppet Managed. What else is out there, and/or what have you found useful?