On the server acting as the “puppet master”, ruby ldap client libraries are required. In the example below our “puppet master” server has already been configured on a ubuntu linux server.

Ensure ruby client libraries are installed:

After verifying the absence of the ruby client libraries we install them below:

--> aptitude search ruby | grep -i ldap
...edited...
p   libldap-ruby1.8                 - OpenLDAP library binding for Ruby 1.8
...edited...

--> aptitude install libldap-ruby1.8
...edited...
Fetched 66.8 kB in 0s (109 kB/s)
Selecting previously deselected package libldap-ruby1.8.
(Reading database ... 63468 files and directories currently installed.)
Unpacking libldap-ruby1.8 (from .../libldap-ruby1.8_0.9.7-1.1_amd64.deb) ...
Setting up libldap-ruby1.8 (0.9.7-1.1) ...

`--> ruby -rldap -e "puts :installed"
installed

Update /etc/puppet/puppet.conf to use LDAP

Change your “/etc/puppet/puppet.conf” [master] section to use ldap for node lookups on the master server. For example, the following should be placed in the /etc/puppet/puppet.conf file underneath the section [master]:

[master]
node_terminus = ldap
ldapserver = odsee.goldcoast.com
ldapbase = ou=hosts,dc=goldcoast,dc=com

Were ‘node_terminus’ was originally using file, but will now use ldap. ‘ldapserver’ should point to a valid ldap server that can be accessed on port 389. ‘ldapbase’ is where the puppet master server will look for node information. We will populate this organizational unit (ou) later on. Once the changes have been saved restart the “puppet master”. The ‘nope.pp’ file should no longer be referenced by the master server. But before discarding the file entirely we need to configure LDAP to add the custom puppet schema for our node definitions.

Adding the Puppet Schema to LDAP Directory Server

Next we need to populate our LDAP server to contain the puppet.schema definitions. I recommend visiting the following url for the latest puppet schema:

https://github.com/puppetlabs/puppet/blob/master/ext/ldap/puppet.schema

Login into your directory server. Copy the contents of ‘puppet.schema’ to a temporary file, for example to: /tmp/98puppet.ldif.tmp. The file as is, as of this writing, cannot be imported into Oracle Directory Server Enterprise (ODSEE) without modification.

The original ‘puppet.schema’ looks like:

bash-3.00# cat > /tmp/98puppet.ldif.tmp
attributetype ( 1.3.6.1.4.1.34380.1.1.3.10 NAME 'puppetClass'
DESC 'Puppet Node Class'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.34380.1.1.3.9 NAME 'parentNode'
DESC 'Puppet Parent Node'
EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
        SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.34380.1.1.3.11 NAME 'environment'
DESC 'Puppet Node Environment'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.34380.1.1.3.12 NAME 'puppetVar'
DESC 'A variable setting for puppet'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

objectclass ( 1.3.6.1.4.1.34380.1.1.1.2 NAME 'puppetClient' SUP top AUXILIARY
DESC 'Puppet Client objectclass'
MAY ( puppetclass $ parentnode $ environment $ puppetvar ))

It can be easily converted with the following script, located at:

http://directory.fedoraproject.org/wiki/Howto:OpenLDAPMigration.

in order to work with ODSEE. For example:

bash-3.00# cd /tmp/

bash-3.00# perl ldif2dsee.pl 98puppet.ldif.tmp > 98puppet.ldif

After Conversion, the puppet schema will look like:

bash-3.00# cat 98puppet.ldif

dn: cn=schema
attributeTypes: ( 1.3.6.1.4.1.34380.1.1.3.10 NAME 'puppetClass' DESC 'Puppet Node Class' EQUALITY cas
eIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'PUPPET')
attributeTypes: ( 1.3.6.1.4.1.34380.1.1.3.9 NAME 'parentNode' DESC 'Puppet Parent Node' EQUALITY case
IgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'PUPPET')
attributeTypes: ( 1.3.6.1.4.1.34380.1.1.3.11 NAME 'environment' DESC 'Puppet Node Environment' EQUALI
TY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'PUPPET')
attributeTypes: ( 1.3.6.1.4.1.34380.1.1.3.12 NAME 'puppetVar' DESC 'A variable setting for puppet' EQ
UALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'PUPPET')
objectClasses: ( 1.3.6.1.4.1.34380.1.1.1.2 NAME 'puppetClient' SUP top AUXILIARY DESC 'Puppet Client 
objectclass' MAY ( puppetClass $ parentNode $ environment $ puppetVar ) X-ORIGIN 'PUPPET')

Copy the resulting file, /tmp/98puppet.ldif, under the ODSEE schema/ path. This is usually under instance-path/config/schema/ :

bash-3.00# cp /tmp/98puppet.ldif /odsee/config/schema/

Restart the LDAP Instance

Before restarting the instance, tail the errors log file, instance-path/logs/errors in one window and in another restart the ldap instance ensuring there were no errors. For example, after restarting the instance:

bash-3.00# dsadm restart /odsee
Directory Server instance '/odsee' stopped

Note: Notice after the restart, the message says “… ‘/odsee’ stopped”. It should have said “… ‘/odsee’ restarted

The errors window should have displayed something similiar to:

[21/Jan/2012:22:25:43 -0500] - slapd shutting down - waiting for 0 threads to terminate
[21/Jan/2012:22:25:43 -0500] - libumem_dummy_thread started.
[21/Jan/2012:22:25:43 -0500] - Waiting for 6 database threads to stop
[21/Jan/2012:22:25:44 -0500] - All database threads now stopped
[21/Jan/2012:22:25:44 -0500] - slapd stopped.
[21/Jan/2012:22:25:47 -0500] - Sun-Directory-Server/11.1.1.3.0 B2010.0630.2254 (64-bit) starting up
[21/Jan/2012:22:25:49 -0500] - Listening on all interfaces port 389 for LDAP requests
[21/Jan/2012:22:25:49 -0500] - Listening on all interfaces port 636 for LDAPS requests
[21/Jan/2012:22:25:49 -0500] - slapd started. 
[21/Jan/2012:22:25:49 -0500] - INFO: 97 entries in the directory database.
...edited...

Verify The Puppet Schema is in LDAP

While still logged into the LDAP server, perform a basic search which should return the schema that was just imported.

bash-3.00# ldapsearch -T -b cn=schema "(objectclass=*)" | grep -i puppet

attributeTypes: ( 1.3.6.1.4.1.34380.1.1.3.11 NAME 'environment' DESC 'Puppet Node Environment' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'PUPPET' )
attributeTypes: ( 1.3.6.1.4.1.34380.1.1.3.10 NAME 'puppetClass' DESC 'Puppet Node Class' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'PUPPET' )
attributeTypes: ( 1.3.6.1.4.1.34380.1.1.3.9 NAME 'parentNode' DESC 'Puppet Parent Node' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'PUPPET' )
attributeTypes: ( 1.3.6.1.4.1.34380.1.1.3.12 NAME 'puppetVar' DESC 'A variable setting for puppet' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'PUPPET' )
objectClasses: ( 1.3.6.1.4.1.34380.1.1.1.2 NAME 'puppetClient' DESC 'Puppet Client objectclass' STRUCTURAL MAY ( puppetClass $ parentNode $ environment $ puppetVar ) X-ORIGIN 'PUPPET' )

Now you should be able to add node information within LDAP.

Add a base node to LDAP

I like to use the command line tool ldapvi for manipulating my ldap entries. I will not go into detail on how to configure ldapvi, but additional information may be found online. Let’s add a base node and assign the “base class” to it. We will place “cn=base”, under the “search base” ou=hosts,cn=goldcoast,dc=com:

--> ldapvi --add -o top -o device -o puppetClient -b cn=base,ou=hosts,cn=goldcoast,cn=com

After invocation, your default editor will open up with a screen similar to this:

# -*- coding: utf-8 -*- vim:encoding=utf-8:
# http://www.lichteblau.com/ldapvi/manual#syntax

### NOTE: objectclass is abstract: top
# structural object class: device
### WARNING: extra structural object class: puppetClient
add cn=base,ou=hosts,cn=goldcoast,cn=com
objectClass: top
objectClass: device
objectClass: puppetClient
cn:
#description:
#l:
#o:
#ou:
#owner:
#seeAlso:
#serialNumber:
puppetClass: base
#parentNode:
#environment:
#puppetVar:

My default editor is “vim” and I uncommented “puppetClass:” in order to use the “base” class for the “base node”. Once done, save and quit the file and you should be presented with authentication to commit the change to ldap — something similiar to:

...edited...
~
/tmp/ldapvi-usdGC1/data: 22 lines, 457 characters.
add: 1, rename: 0, modify: 0, delete: 0
Action? [yYqQvVebB*rsf+?] b

--- Login
Type M-h for help on key bindings.

Filter or DN: 
    Password: 

Cheers,
-swinful

# zfs sharesmb=on tank

which should implicitly enable the SMF: svc:/network/smb/server:default

What was actually missing, since we are in an Active Directory environment was joining our Solaris host to the domain and mapping corresponding Windows users to Unix users — provided the Windows and Unix usernames are the same and in this case they were.

Join Solaris to the Active Directory domain:

# smbadm join -u administrator goldcoast.com

At his point the Windows shares were now accessible, but you may have noticed the file mappings were wrong. For example, on the Windows side of things if you created a new file the owner and group would appear differently on the Unix side, similiar to the below listing:

# ls -ltr
   -rwx------+ 1 2147540993 2147483653          0 May 10 16:24 New Text Document.txt                    

And with permissions like that, in a shared environment there are sure to be a lot of complaints.

To map all AD users that are part of domain goldcoast.com, considering the local unix accounts have the same name we performed:

# idmap add "winuser:*@goldcoast.com" unixuser:*

And samba is enabled. Try it, try to access the share from Windows using

Start -> Run: \\army\tank

`--> apropos perl | grep doc
perlapi(1)               - autogenerated documentation for the perl public API
perldoc(1)               - Look up Perl documentation in Pod format
perlintern(1)            - autogenerated documentation of purely internal Perl functions
perlplan9(1)             - Plan 9-specific documentation for Perl
perlpod(1)               - the Plain Old Documentation format Xref "POD plain old documentation"
perltoc(1)               - perl documentation table of contents
perlvms(1)               - VMS-specific documentation for Perl

What stood out to me was perltoc(1). And, it is what I used for the basis of starting to learn perl. For example perltoc(1) — like its’ name suggest will provide a brief table of contents for the rest of the perl documentation set. I used it to scan for areas that interested me about perl.

`--> man perltoc | col -bx | egrep "perl.+ -+ .*" | sed 's/^ *//' | more
perltoc - perl documentation table of contents
perlintro -- a brief introduction and overview of Perl
perlreftut - Mark's very short tutorial about references
perldsc - Perl Data Structures Cookbook
perllol - Manipulating Arrays of Arrays in Perl
perlrequick - Perl regular expressions quick start
perlretut - Perl regular expressions tutorial
perlboot - Beginner's Object-Oriented Tutorial
perltoot - Tom's object-oriented tutorial for perl
perltooc - Tom's OO Tutorial for Class Data in Perl
perlbot - Bag'o Object Tricks (the BOT)
perlperf - Perl Performance and Optimization Techniques
perlstyle - Perl style guide
perlcheat - Perl 5 Cheat Sheet
perltrap - Perl traps for the unwary
perldebtut - Perl debugging tutorial
perlfaq - frequently asked questions about Perl
perlfaq  - this document, perlfaq1 - General Questions About Perl,
perlfaq2 - Obtaining and Learning about Perl, perlfaq3 -

Once I got feet wet I decided to purchase one of the O’ Reilly Books: Programming Perl 4th Edition.And, I also found the following sites useful: http://learn.perl.org and http://perldoc.perl.org.

...edited...
--->  Configuring gnucash
--->  Building gnucash
--->  Staging gnucash into destroot
--->  Installing gnucash @2.4.7_1
--->  Activating gnucash @2.4.7_1
--->  Cleaning gnucash
5150.53s user 1790.23s system 109% cpu 1:45:58.98s total

Now, that took long enough — one hour and forty five minutes! Thought I would share. -;)

dbx on AIX is part of the bos.adt.debug (Base Application Development) software bundle. If you have the installation media inserted (usually the first CD/DVD), typically accessible via the device ‘cd0′ you can install dbx by performing the following:

# smitty install

References:

http://www-01.ibm.com/support/docview.wss?uid=swg21222456

But what if the provider uses the full capabilities of TR-069 for profit and gain? That I would not be the least bit surprised. After all they do technically own the device while the customer has service with them. But what if a mid-night shift engineer used the capabilities of TR-069 to gain entry into a customers home network to snoop around? Would the customer know? Could the customer even prevent remote access into their leased modem or router and ultimately their private home network? First, what exactly is TR-069?

According to Wikipedia:

TR-069 (Technical Report 069) is a DSL Forum (which was later renamed as Broadband Forum) technical specification entitled CPE WAN Management Protocol (CWMP). It defines an application layer protocol for remote management of end-user devices.

In other words, TR-069 is a WAN Management Protocal implemented in client devices such as home routers, set-top boxes and similar equipment leased from ISP’s or cable providers. These client devices are also referred to as CPE’s or a Customer Premise Equipment. TR-069 is the technology that allows vendors to remotely interact with their CPE for such purposes as initial device configuration, troubleshooting and basic management of the device such as performing remote backups or firmware upgrades. This allows vendors to cut costs on field technicians that would have otherwise been dispatched to a customer’s home or office. The protocol allows for communication to take place via SOAP/HTTP, between the CPE and the vendors Auto Configuration Servers (ACS). With TR-069, communication can either be initiated from the vendor side or the customer side without the customer’s knowledge. An ACS can be thought of as a single point of management for all customer devices [2].

So, would the customer know if “someone” was snooping around? Possibly, but they would definitely have to be proactive and check the logs from time to time. Could the customer even prevent remote access into their leased modem or router and ultimately their private home network? This is a big NO! At least not with the equipment provided to them by the manufacturer or their ISP. Trying to disable the abilities of Tr-069 once implemented in a device is damn near impossible, especially when attempted using the FiOS router itself. Check out this screenshot:

You will notice under the “Delete” column, what would have been an option to delete this rule from the outside has been removed. Another example to show the “Verizon FiOS Service” cannot be blocked is something you can test yourself. For example, if you have Internet with FiOS and know your public-ip port “4567″ will be open. Attempting to connect to it via a web-browser should present you with a login prompt. However, not just anyone can connect and I would be surprised if you could get that Login/Password pair. But, what if someone figured out the pair? Or what is an employee at the ISP wanted to snoop around?

Juniper SSG 5 Wireless

Using a Juniper SSG5 w/ ScreenOS as the main router for the Verizon FiOS service provides a number of features and benefits over using Verizon’s own wireless router. Some of which are:

1. Built-in antivirus, antispam and web filtering, allowing for the possibility of stopping all viruses and malware before they damage your network.
2. Deep (packet) Inspection that has the potential to prevent application-level attacks from flooding the network.
3. Seven fixed 10/100 interfaces that can each operate individually or as a group in layer 2 and or layer 3 mode, while providing high-speed LAN connectivity and redundant WAN connectivity if so desired.
4. And much, much more. Here is the full list of features and benefits for the Secure Services Gateways by Juniper Networks (PDF).

Also, worth nothing the is the fact that Verizon’s ActionTec routers use TR-069, a WAN management protocol, that allows the device, also known as the Customer Premises Equipment (CPE), to get and send data to authorized parties or servers. By now having the Verizon ActionTec router behind our SSG we can effectively control this type of communication and even possibly capture the traffic it sends back and forth. There has been chatter on slashdot.org namely the article, Verizon Changing Users Router Passwords, in the past indirectly about this and the infamous open port 4567 on public facing ActionTec routers. My personal experience with TR-069 is later in this post.

We have the Verizon wireless ActionTec, model MI424WR at home and it sits behind our SSG5 with an additional coaxial connection at the back of it. This coaxial is use for connecting one or more set-top boxes (STB) to receive video or provide data in the case of a MoCa setup. When using the SSG5 router from Juniper, we do not completely eliminate the use Verizon’s wireless router as it is needed for TV/Cable service via the coax cable, something the SSG5 cannot provide.  I have found, though your mileage might vary, when FiOS is first setup. By default, I am told, technicians perform a MoCA setup, unless a non-MoCA is requested by the customer (what I requested).

MoCA stands for Multimedia over Coax Alliance(MoCA) protocol, which allows for both data and video over a single coaxial cable. Hence, with a MoCA setup, there is no need to run an ethernet cable directly from the Optical Network Terminal (OTN) usually on the side of the home to the FiOS router inside the home. Instead a single coaxial cable is ran that allows both data and video and sometimes voice. So, if you are to use an SSG firewall or similar device with Verizon FiOS you will most likely want the non-MoCA setup, which is what I have for my SSG and it works great! Once working, the SSG needs to be configured in order to allow Verizon’s router to sit behind it using its WAN port. The WAN port of the ActionTec router needs access to the Internet for NAT of the of LAN and Wireless devices that sit behind it. This includes the STB as they need access to the Internet for retrieving channel listing. I will explain this setup via this rough diagram:

FiOS SSG Setup

The setup is pretty straight forward. Again, this setup requires that:

1. A Verizon tech provision a Non-MoCA setup.
2. An Ethernet cable is ran from the Optical Network Terminal (ONT), a Non-MoCA configuration, directly to a port of the SSG router (eth0/0) instead of the WAN port of the Verizon router.
3. The WAN port of the Verizon ActionTec router will connect to a physical port of the SSG to obtain an IP address via DHCP.

The initial configuration to setup the SSG 5 will not be discussed in detail, but I assume the reader knows how to access the SSG device via the serial-console and or one of the network ports. In this setup of the SSG we:

1. Configure eth0/0 as the WAN interface in the Untrust security zone allow it to act as a DHCP client.
2. Configure eth0/4 — eth0/6 to bind to bgroup0 on network: 192.168.2.0/24, in the Trust security zone (the WAN port of the Verizon ActionTec connects to once of these ports.)
3. Configure bgroup0 as a DHCP server to distribute IPs in the range: 192.168.2.30 — 192.168.2.60..

Configure eth0/0 as the WAN interface in the Untrust security zone allowing it to act as a DHCP client.

set interface "ethernet0/0" zone "Untrust"
set interface ethernet0/0 route
set interface ethernet0/0 ip manageable
set interface ethernet0/0 manage ping
set interface ethernet0/0 manage ssl
set interface ethernet0/0 dhcp client enable
set interface ethernet0/0 route-deny

Afterwards verify that ethernet0/0 on the SSG has a public verizon IP address. You may have to wait a bit up to five minutes for the new IP to come in. Worst case, you may have to call Verizon to break the IP lease. There really is no need to restart the SSG. It will actively request an IP until it is satisfied.

Configure eth0/4 — eth0/6 to bind to bgroup0 on network: 192.168.2.0/24, in the Trust security zone.

set interface "bgroup0" zone "Trust"
set interface bgroup0 port ethernet0/4
set interface bgroup0 port ethernet0/5
set interface bgroup0 port ethernet0/6
set interface bgroup0 ip 192.168.1.1/24
set interface bgroup0 ip manageable

Configure bgroup0 as a DHCP server to distribute IPs in the range: 192.168.2.30 — 192.168.2.60.

set interface bgroup0 dhcp server service
set interface bgroup0 dhcp server auto
set interface bgroup0 dhcp server ip 192.168.1.30 to 192.168.1.60

Afterwards, plug-in the Verizon ActionTec router to one of these ports, ethernet0/4, and it should receive an IP in the defined range. At this point, any communication that is to take place originating from the ActionTec must pass through the SSG.

All of the above command-line can be configured via the SSG’s web interface as well. I don’t show that here as it is pretty much self-explanatory.

Once steps 1 — 3 are complete. The WAN port of the Verizon ActionTec router may be plugged into bgroup0 to receive an IP via DHCP. Next, the policy “Trust” to “UnTrust” should be configured to allow traffic for all devices in the Trust network out to the Untrust. It is left up to the reader to allow or deny specific traffic.

Configure DefaultAllow Policy from Trust to Untrust for devices part of bgroup0

set policy name "DefaultAllow" from "Trust" to "Untrust" "Any" "Any" "ANY" permit log

My personal experience with TR-069

Since the switch to have Verizon’s router “piggy back” my SSG I have noticed periodic communication between our Verizon ActionTec router and at least two public IP addresses. Communication is initiated from the Verizon ActionTec router or CPE device about every 10 to 15 minutes to the following two IP addresses: 72.76.255.44 and 72.76.255.36. Active communication takes place on tcp port 80 and UDP port 6794.

From a whois query and reverse lookup both IPs belong to Verizon and not some third party — at least not by first glance:

OrgName: Verizon Online LLC
OrgId: VRIS
Address: 22001 Loudoun County Parkway
City: Ashburn
StateProv: VA
PostalCode: 20147
Country: US
RegDate:
Updated: 2010-08-17
Ref: http://whois.arin.net/rest/org/VRIS

A reverse lookup shows one (72.76.255.36) IP as a DNS server and the other (72.76.255.44) as something else, probably used for channel listing update by the looks of the hostname:

$ dig -x 72.76.255.36 | egrep "SOA|PTR"
255.76.72.in-addr.arpa.	834	IN	SOA	ns5.verizon.net. dns.verizon.com. 2010073001 86400 3600 604800 86400

$ dig -x 72.76.255.44 | egrep "SOA|PTR" 
44.255.76.72.in-addr.arpa. 86309 IN	PTR	mercuryipg.frhdnjbbh09.fiostv.verizon.net.

In another post, I plan on snooping the traffic initiated by the Verizon ActionTec router to the named IPs above. Stay tuned!

Cheers,
-swinful

`--> sudo puppet agent --no-daemonize --test
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from source(s) puppet://<server-name>/plugins
info: Caching catalog for <fqdn>
info: Applying configuration version '1321291410'
err: /Stage[main]//Package[ipcalc]/ensure: change from absent to present failed: Execution of '/opt/local/bin/port upgrade ipcalc' returned 1: Error: ipcalc is not installed
To report a bug, see <http://guide.macports.org/#project.tickets>

notice: Finished catalog run in 61.49 seconds
Changes:
            Total: 1
Events:
          Failure: 1
            Total: 1
Resources:
          Changed: 1
           Failed: 1
      Out of sync: 1
            Total: 8
Time:
   Config retrieval: 0.38
       Filebucket: 0.00
          Package: 30.99
         Schedule: 0.00
60.51s user 2.53s system 99% cpu 1:03.12s total

The site manifest, ‘site.pp’, had the following definitions:

Package {
  provider => $operatingsystem ? {
    darwin => darwinport,
  }
}

package {'ipcalc':
  ensure => installed,
}

stating that the packaging system to use on a Mac (darwin) is the ‘darwinport’ port system. I use ‘Mac Ports’, but the only provider I could find close enough was ‘darwinport’ from the output of “puppet describe -s package“:

> puppet describe -s package
...edited...
Providers
---------
    aix, appdmg, apple, apt, aptitude, aptrpm, blastwave, darwinport, dpkg,
    fink, freebsd, gem, hpux, macports, nim, openbsd, pkg, pkgdmg, portage,
    ports, portupgrade, rpm, rug, sun, sunfreeware, up2date, urpmi, yum,
    zypper

Looking at the initial error,

“‘/opt/local/bin/port upgrade ipcalc’ returned 1: Error: ipcalc is not installed…“,

lead me to the realization that on the command-line “port installed” and not “port upgrade” should have been executed by puppet. But, with ‘Mac Ports’ as the package management system using “port upgrade ” to install a non-existent port will indeed fail. Apparently this was not the case with the original darwinport packaging system. This was confirmed by inspecting the puppet provider source file: “/opt/local/lib/ruby/site_ruby/1.8/puppet/provider/package/darwinport.rb” on the local system. It can be found with the command:

--> port contents puppet | grep darwin                                  
 /opt/local/lib/ruby/site_ruby/1.8/puppet/provider/package/darwinport.rb

Looking at the file confirmed the “install” function definition was relying on “port upgrade” to ensure that even non-existent packages should be installed:

 
45 
46   def install
47     should = @resource.should(:ensure)
48 
49     # Seems like you can always say 'upgrade'
50     output = port "upgrade", @resource[:name]
51     if output =~ /^Error: No port/
52       raise Puppet::ExecutionFailure, "Could not find package #{@resource[:name]}"
53     end
54   end
55 

I changed the code on line number 50 to instead read “output = port “install”, @resource[:name]” and that fixed the problem. However, since my current system is using “Mac Ports” I would like to specify “macports” as a provider instead of ‘darwinport’ in my site manifest. To accomplish that I simply copied the provider file for “darwinport.rb to macports.rb”:

--> sudo cp /opt/local/lib/ruby/site_ruby/1.8/puppet/provider/package/darwinport.rb /opt/local/lib/ruby/site_ruby/1.8/puppet/provider/package/macports.rb

and made the below changes specified in the diff output below:

--- /opt/local/lib/ruby/site_ruby/1.8/puppet/provider/package/darwinport.rb	2011-10-31 11:12:17.000000000 -0400
+++ /opt/local/lib/ruby/site_ruby/1.8/puppet/provider/package/macports.rb	2011-11-14 12:00:02.000000000 -0500
@@ -1,7 +1,7 @@
 require 'puppet/provider/package'
 
-Puppet::Type.type(:package).provide :darwinport, :parent => Puppet::Provider::Package do
-  desc "Package management using DarwinPorts on OS X."
+Puppet::Type.type(:package).provide :macports, :parent => Puppet::Provider::Package do
+  desc "Package management using Mac Ports on OS X."
 
   confine :operatingsystem => :darwin
   commands :port => "/opt/local/bin/port"
@@ -47,6 +47,16 @@
     should = @resource.should(:ensure)
 
     # Seems like you can always say 'upgrade'
+    output = port "install", @resource[:name]
+    if output =~ /^Error: No port/
+      raise Puppet::ExecutionFailure, "Could not find package #{@resource[:name]}"
+    end
+  end
+
+  def upgrade
+    should = @resource.should(:ensure)
+
+    # Seems like you can always say 'upgrade'
     output = port "upgrade", @resource[:name]
     if output =~ /^Error: No port/
       raise Puppet::ExecutionFailure, "Could not find package #{@resource[:name]}"

Now I am able to change my site manifest, site.pp, to read:

Package {
  provider => $operatingsystem ? {
    darwin => macports,
  }
}

package {'ipcalc':
  ensure => installed,
}

and it executes without issues when installing a new port:

`--> sudo puppet agent --no-daemonize --test
Password:
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from source(s) puppet://<server-name>/plugins
info: Caching catalog for <fqdn>
info: Applying configuration version '1321293994'
notice: /Stage[main]//Package[ipcalc]/ensure: created
notice: Finished catalog run in 63.30 seconds
Changes:
            Total: 1
Events:
          Success: 1
            Total: 1
Resources:
          Changed: 1
      Out of sync: 1
            Total: 8
Time:
   Config retrieval: 0.44
       Filebucket: 0.00
          Package: 32.58
         Schedule: 0.00
60.94s user 2.84s system 92% cpu 1:09.09s total

`--> port installed ipcalc
The following ports are currently installed:
  ipcalc @0.41_0 (active)

Just received my reminder to attend the the Oracle Solaris 11 Launch, on Wednesday, November 9, 2011. This event will be at:

Gotham Hall
1356 Broadway at 36th Street
New York, NY 10018

and I am definitely looking forward to it. This release is geared towards Cloud computing, but as of now there has not been much on what new stunning innovations we will see out of this release of Solaris. Stay tuned!

Below I describe how to properly use the OpenLDAP Sudoer’s LDAP schema, which is commonly found with sudo source and binary distributions as schema.OpenLDAP. We will take this schema and make it functional with our instance of Oracle Directory Server Enterprise Edition (ODSEE). Unfortunately, one cannot just use the schama.OpenLDAP without prior modification when using ODSEE. The original schema.OpenLDAP has to be changed, slightly, to work well with ODSEE.

As the example below illustrates our custom schema file should be named accordingly, prefixed with a number. The number should be higher than any of the default ldif’s in the ‘instance schema folder’, but less than or equal to 99. For example, here are the default listings of the ldif’s in my /config/schema/ folder:

bash-3.00# ls | pr -3
00core.ldif             50ns-calendar.ldif      50ns-media.ldif
00ds6pwp.ldif           50ns-certificate.ldif   50ns-mlm.ldif
05rfc2247.ldif          50ns-compass.ldif       50ns-msg.ldif
05rfc2927.ldif          50ns-delegated-admin.ld 50ns-netshare.ldif
11rfc2307.ldif          50ns-directory.ldif     50ns-news.ldif
20subscriber.ldif       50ns-legacy.ldif        50ns-proxy.ldif
25java-object.ldif      50ns-mail.ldif          50ns-value.ldif
28pilot.ldif            50ns-mcd-browser.ldif   50ns-wcal.ldif
30ns-common.ldif        50ns-mcd-config.ldif    50ns-web.ldif
50iplanet-servicemgt.ld 50ns-mcd-li.ldif        98sudo.ldif
50ns-admin.ldif         50ns-mcd-mail.ldif      99user.ldif

Nothing will prevent you from prefixing your custom schema file with ’00′, but doing so means the custom schema may be loaded before more important system schemas. And, this could lead to stability issues down the road. While the contents of our below custom schema.OpenLDAP file may be appended to the ODSEE ‘99user.ldif‘ file we will create our own seperate file, 98sudo.ldif and modify it. Again, one may not just copy the sudoers schema.OpenLDAP file as-is without modifying its contents and expect it to work with Oracle Directory Server. Here is the creation of the schema:

# cat > 98sudo.ldif <<HERE 
# The following schema, in OpenLDAP format, is included with sudo source and
# binary distributions as schema.OpenLDAP.
#
#
dn: cn=schema
objectclass: top
objectclass: ldapSubentry
objectclass: subschema
cn: schema
#
# aci to ensure that the standard schema attributes are visible to
# all LDAP clients (anonymous access).
#
aci: (target="ldap:///cn=schema")(targetattr !="aci")(version 3.0;acl "anonymous, no acis"; 
  allow (read, search, compare) userdn = "ldap:///anyone";) 
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' DESC 'User(s) who may run sudo' 
  EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO')
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.2 NAME 'sudoHost' DESC 'Host(s) who may run sudo' 
  EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO')
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.3 NAME 'sudoCommand' DESC 'Command(s) to be executed by sudo' 
  EQUALITY caseExactIA5Match 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO')
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.4 NAME 'sudoRunAs' DESC 'User(s) impersonated by sudo' 
  EQUALITY caseExactIA5Match 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO')
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.5 NAME 'sudoOption' DESC 'Options(s) followed by sudo' 
  EQUALITY caseExactIA5Match 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO')
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.6 NAME 'sudoRunAsUser' DESC 'User(s) impersonated by sudo' 
  EQUALITY caseExactIA5Match 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO')
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.7 NAME 'sudoRunAsGroup' DESC 'Group(s) impersonated by sudo' 
  EQUALITY caseExactIA5Match 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO')
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.8 NAME 'sudoNotBefore' DESC 'Start of time interval for which the entry is valid' 
  EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 X-ORIGIN 'SUDO')
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.9 NAME 'sudoNotAfter' DESC 'End of time interval for which the entry is valid' 
  EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 X-ORIGIN 'SUDO')
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.10 NAME 'sudoOrder' DESC 'an integer to order the sudoRole entries' 
  EQUALITY integerMatch ORDERING integerOrderingMatch 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'SUDO')
objectClasses: ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) 
  MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ sudoNotBefore 
  $ sudoNotAfter $ sudoOrder $ description ) X-ORIGIN 'SUDO')
HERE

Note: Depending on how your copy & paste worked, you may want to consider having all ‘attribute*’ entry lines above on just one line to avoid issues with slapd loading the custom file.

Once done, restart the instance while tailing the error log residing under “//logs/error“. This allows you to know right away if something went wrong!

So in one window tail the error log:

# tail -f /<instance-path>/logs/errors
...edited...
[07/Nov/2011:16:42:19 -0500] - Closing all interfaces port 389 for LDAP requests
[07/Nov/2011:16:42:19 -0500] - Closing all interfaces port 636 for LDAPS requests
[07/Nov/2011:16:42:19 -0500] - DEBUG - conn=-1 op=-1 msgId=-1 -  slapd shutting down - signaling operation threads
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 27 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 22 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 19 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 18 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 17 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 16 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 15 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 12 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 11 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 8 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 6 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 4 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 2 threads to terminate
[07/Nov/2011:16:42:19 -0500] - slapd shutting down - waiting for 0 threads to terminate
[07/Nov/2011:16:42:19 -0500] - libumem_dummy_thread started.
[07/Nov/2011:16:42:19 -0500] - Waiting for 6 database threads to stop
[07/Nov/2011:16:42:20 -0500] - All database threads now stopped
[07/Nov/2011:16:42:20 -0500] - slapd stopped.
[07/Nov/2011:16:42:22 -0500] - Sun-Directory-Server/11.1.1.3.0 B2010.0630.2254 (64-bit) starting up
[07/Nov/2011:16:42:23 -0500] - Listening on all interfaces port 389 for LDAP requests
[07/Nov/2011:16:42:23 -0500] - Listening on all interfaces port 636 for LDAPS requests
[07/Nov/2011:16:42:23 -0500] - slapd started.
[07/Nov/2011:16:42:23 -0500] - INFO: 88 entries in the directory database.
[07/Nov/2011:16:42:23 -0500] - INFO: add:0, modify:0, modrdn:0, search:0, delete:0, compare:0, bind:0 since startup.

While in the other window restart the instance:

# dsadm stop /<instance-path>
# dsadm start /<instance-path>

Or, you could have restarted in one command with:

# dsadm restart /<instance-path>

Verify that the new attributes exist within the LDAP database by performing a basic ldap search against the directory server:

bash-3.00# ldapsearch -T -b cn=schema "(objectclass=*)" | grep -i sudo
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' DESC 'User(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.9 NAME 'sudoNotAfter' DESC 'End of time interval for which the entry is valid' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.4 NAME 'sudoRunAs' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.3 NAME 'sudoCommand' DESC 'Command(s) to be executed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.6 NAME 'sudoRunAsUser' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.5 NAME 'sudoOption' DESC 'Options(s) followed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.10 NAME 'sudoOrder' DESC 'an integer to order the sudoRole entries' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.8 NAME 'sudoNotBefore' DESC 'Start of time interval for which the entry is valid' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.7 NAME 'sudoRunAsGroup' DESC 'Group(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.2 NAME 'sudoHost' DESC 'Host(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
objectClasses: ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' DESC 'Sudoer Entries' STRUCTURAL MUST cn MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $ sudoOrder $ description ) X-ORIGIN 'SUDO' )

Before wrapping things up, it is a good idea to also create an index of the attribute ‘sudoUser’. For example, if your base suffix is “dc=goldcoast,dc=com“, you can create the index for the attribute ‘sudoUser’ by performing:

# dsconf create-index dc=goldcoast,dc=com sudoUser

And verify:

# dsconf list-indexes
Enter "cn=Directory Manager" password: 
...edited...
dc=goldcoast,dc=com           sudoUser 
...edited...

References:

1. When Creating Custom Schema Files, Oracle Fusion Middleware Administration Guide for Oracle Directory Server
2. Extending Schema With a Custom Schema File Oracle Fusion Middleware Administration Guide for Oracle Directory Server