9 Replies Latest reply: Dec 6, 2012 5:44 PM by 894642 RSS

    Using SC Profile Templates - {{AI_HOSTNAME}} variable not being used

      I'm having trouble with using AI System Configuration Profile Templates.

      I cannot get the AI_HOSTNAME, AI_IPV4 and AI_NETWORK variables to be passed onto the install client. Has anyone had any success with this?

      Amongst all the usual stuff, my SC template contains these lines:
      <propval type="astring" name="nodename" value="{{AI_HOSTNAME}}"/>
      <propval type="net_address_v4" name="static_address" value="{{AI_IPV4}}/25"/>
      <propval type="net_address_v4" name="default_route" value="{{AI_NETWORK}}"/>

      The lines are taken from the "Installing Oracle Solaris 11 Systems" example.

      Then I submit to the AI service
      # installadm create-client -n s11-sparc -e aa:bb:cc:dd:ee:ff
      # installadm create-profile -n s11-sparc -f <profile_file> -p <profile_name> -c mac="aa:bb:cc:dd:ee:ff"

      The documentation shows that afterwards I should be able to do "# installadm export -n s11-sparc -p <profile_name>" and see the {{AI_placeholders}} replaced with the variable values. But all I see are the unchanged {{AI_placeholders}}.

      I have tried exporting the variables first as suggested in the installation guide, e.g.,
      # export AI_HOSTNAME=myhost; export AI_IPV4=; export AI_NETWORK=
      # installadm create-profile -n s11-sparc -f <profile_file> -p <profile_name> -c mac="aa:bb:cc:dd:ee:ff"

      I have tried the other method shown in the 11.0 installation guide. In this case the sc profile isn't found during AI (which makes sense because the -c are selection criteria, AI can't match what isn't defined yet).
      -c hostname="myhost" -c ipv4="" -c network="

      I have been referring to Chapter 11 of "Installing Oracle Solaris 11 Systems". The documentation for Solaris 11.0 and Solaris 11.1 is quite different. The 11.0 guide looks more correct than the 11.1 guide. But neither are working for me.

      11.0 http://docs.oracle.com/cd/E23824_01/html/E21798/glhwo.html
      11.1 http://docs.oracle.com/cd/E26502_01/html/E28980/glhwo.html

      Additionally the man page examples are quite different. http://docs.oracle.com/cd/E26502_01/html/E29031/installadm-1m.html Example 20 seems particularly nonsensical.

      When the client installs, everything else in the defined in the sc profile is correct, but the hostname stays "solaris" and the IP and default route are the ones assigned by DHCP. The {{AI varaibles}} I passed in are ignored.

      My environment:
      AI server is Solaris 11.1 SRU 1.0.4 (kernel@0.5.11,5.11- and installadm@0.5.11,5.11-
      IPS repo contains Solaris 11 11/11 (up to SRU 13-04) and Solaris 11.1 (up to SRU 1.0.4)
      Install client is a logical domain on SPARC T4-2 (ldomsmanager@,5.11-

      Missing JumpStart :-(


      In the Oracle Knowledgebase the only reference to AI_HOSTNAME is this bug
      Says it was fixed in Solaris 11. Maybe it broke again, or maybe I'm just missing something.

      Edited by: user1077157 on Dec 3, 2012 8:30 PM
        • 1. Re: Using SC Profile Templates - {{AI_HOSTNAME}} variable not being used

          As of build 8, the behavior has changed: the template placeholders will be stored unaltered in the profile, to be replaced with the actual client system criteria values at the time of the automated installation (bug 15763055).

          • 2. Re: Using SC Profile Templates - {{AI_HOSTNAME}} variable not being used
            Dave Miner-Oracle
            You seem to be referring to the Solaris 11 documentation but using 11.1. This feature was changed in 11.1 so that the values are expanded dynamically at installation time based on the values acquired using DHCP or supplied in the network-boot-arguments OBP variable. If you want to expand profiles in the old way, we'd suggest using normal Unix text-processing tools to pre-process the profiles prior to registration with installadm, as that's effectively all you were getting before.
            • 3. Re: Using SC Profile Templates - {{AI_HOSTNAME}} variable not being used
              Thanks, William,

              Helps to have the Bug ID. My mistake was to search for "sc profile template solaris 11" and "system configuration profile template solaris 11" in the MOS bug database.

              • 4. Re: Using SC Profile Templates - {{AI_HOSTNAME}} variable not being used
                Hello Dave,

                I am using Solaris 11.1. Yes, I was looking in both 11.0 (11 11/11) and 11.1 Installation guides. The reason was that when I found things not working for me I checked the 11.1 guide, when I read http://docs.oracle.com/cd/E26502_01/html/E28980/glhwo.html I thought "Hey, that's not how I remember it" so I checked the 11.0 guide and found that they are quite different.

                The {{AI_HOSTNAME}} (and the others) are not working for me because I am not passing values from DHCP or the network-boot-arguments OBP variable.

                To my way of thinking setting values in /etc/netboot or OPB network-boot-arguments is quite different to exporting variables in the shell on the AI server, so I didn't make that connection mentally.

                As I mentioned, the 11.1 man pages and installation guide have both been changed. Neither mentions the fact that the behaviour is different to that of 11.0, why it was changed or what has to be done differently. The '11.1 What's New' PDF http://www.oracle.com/technetwork/server-storage/solaris11/documentation/solaris11-1-whatsnew-1732377.pdf doesn't mention changes to profiles in the Installation section either.

                11.1 Installing guide chapter 14 has details about the OBP network-boot-arguments, I saw that a few weeks back and thought "Cool , SPARC doesn't need DHCP fiddling any more". But there's nothing there that makes it obvious that something has changed with SC Profiles or how the variables are retrieved at install time. I think http://docs.oracle.com/cd/E26502_01/html/E28980/glhwo.html should have some references to http://docs.oracle.com/cd/E26502_01/html/E28980/clients.html

                • 5. Re: Using SC Profile Templates - {{AI_HOSTNAME}} variable not being used
                  Getting somewhere now (two out of three).

                  Manifest has:
                  <propval type="astring" name="nodename" value="{{AI_HOSTNAME}}"/>
                  <propval type="net_address_v4" name="static_address" value="{{AI_IPV4}}/25"/>
                  <propval type="net_address_v4" name="default_route" value="{{AI_NETWORK}}"/>

                  I set the OBP network-boot-arguments
                  ok setenv network-boot-arguments host-ip=,router-ip=,subnet-mask=,hostname=build06,file=

                  After installation I saw that {{AI_HOSTNAME}} and {{AI_IPV4}} have been retrieved properly but {{AI_NETWORK}} shows the network's subnet ID not the default route.

                  # egrep "nodename|net_address_v4" /system/volatile/profile/profile_build06.UPU2yq.xml
                  <propval type="astring" name="nodename" value="build06"/>
                  <propval type="net_address_v4" name="static_address" value=""/>
                  <propval type="net_address_v4" name="default_route" value=""/>

                  I conclude that {{AI_NETWORK}} does not use the router-ip=<n.n.n.n> in OBP network-boot-arguments, it derives the subnet ID from the host-ip and subnet-mask

                  In the 11.0 Install Guide {{AI_NETWORK}} was used as the place holder for the default route. The 11.1 Install Guide no longer uses this example, so I assume it has been deprecated.

                  So how do I pass in the correct default_route to the SC profile template?
                  • 6. Re: Using SC Profile Templates - {{AI_HOSTNAME}} variable not being used
                    There is presently no template variable to represent the default router IP address; the template variables are limited to the criteria used in AI profile lookups.
                    Templating is not offered in Jumpstart, and it is a relatively new idea. We are interested in hearing new use cases to justify support for additional template variables.
                    As you wrote, AI_NETWORK indicates the subnet. I do not think that AI_NETWORK has changed.

                    Thank you for explicitly pointing out the documentation discrepancies.
                    • 7. Re: Using SC Profile Templates - {{AI_HOSTNAME}} variable not being used
                      Hi William,

                      Thanks for confirming that there is no current template variable to represent the default router IP address. That's what I had concluded but I wanted to be sure of it before I a put a work around in place. As you said, this templating is new, but that's why I wanted to investigate because it looks like it could solve a few problems for me.

                      I reckon you're right AI_NETWORK didn't change between 11.0 and 11.1. It's just that the doco changed in the meantime and some months had passed since I last tried to use it. In September (we were on 11 11/11 SRU 8) I couldn't get AI_NETWORK to work as the default route as indicated in the 11.0 installation guide, so I put the IP addresses of the routers in my SC profiles and made a note to come back to it later. After updating to 11.1 I came back to it and found it still didn't work, but it wasn't working for different reasons.

                      Here is our use case:

                      We would prefer not to rely on DHCP for providing configuration data at install time. This is for operational and change mangagement reasons rather than technical. In our organisation there is no DCHP in the Production Data Centres, IP configuration is static and that is the end of the story. DHCP is available in some parts of pre-production environments. wanboot is available most places.

                      So we need a provisioning mechanism that can use DHCP if it is available, but use something else otherwise. OBP network-boot-arguments seems to be the "something else" for SPARC network installations. (We'll also have to provide distribution constructor ISO images for installing clients in new sites where the network infrastructure is not complete -- but that's another story).

                      In parts of the network where DHCP is allowed, it may not be set up. This can take several weeks to be implemented because it crosses several lines of business. The security team have to set up ACLs in the firewalls, the network team have to configure ip-helpers on the switches to pass DHCP requests along, another part of the network team have to configure the routes, the AD team have to provision a new DHCP range, scope and next-server value to direct to the AI server, the DNS team have to create placeholder A and PTR records. Some tasks can occur concurrently although others cannot. Then we add change control, approval processes, documenation updates and liaison with outsourcing providers to all this... it becomes a non-trivial case.

                      If the field engineer who racks and cables the server to the management vlan (or the sysadmin that creates a new LDom) can simply add some OBP variables then 'boot net - install' that will save a heap of time and money.

                      I don't think that we are unique in our requirements. I've worked in several organisations where there have been similar contraints.

                      That's why I would like two more AI_ variables for SC Profiles, namely AI_ROUTER and AI_NETMASK. These would map to the router-ip and subnet-mask in the OBP network-boot-arguments.

                      For consistency with AI_IPV4 maybe they should be AI_ROUTERV4 and AI_NETMASKV4. The existing AI_NETWORK should probably be AI_NETWORKV4

                      In the meantime, the workaround I mentioned will be a first boot script called by an SMF service. It will look for eeprom network-boot-arguments. If none are defined, nothing will happen. Otherwise, if the OBP host-ip matches the current IP and the OBP hostname matches the current hostname and the OPB router-ip does not match current default route, the script will assume that the client has been freshly built with "boot net - install" (I might check a few things in /var/log/install/install_log too). It will then delete the default route and add a new one using the OBP router-ip. It'll then clear the OPB network-boot-arguments and restart the sendmail and dns client services.

                      The build team will then have the option of creating an SC profile from the template with AI_ placeholders or creating an SC profile with specific values, In both cases they can set the OBP network-boot-arguments and bypass DHCP.



                      Thought I should add the reasoning for AI_NETMASK (aside from the fact that it is grabbable because it is in the OBP network-boot-arguments list).

                      I envision using AI_NETMASK to reduce the number of SC profiles I will need, for example

                      Service/Profile Criteria
                      net22 netmask =
                      net23 netmask =
                      net24 None
                      net25 netmask =
                      net26 netmask =
                      net27 netmask =
                      net28 netmask =

                      The net+NN+ profiles themselves will be identical except for one thing, the CIDR notation subnet bits at the end.
                      +<propval type="net_address_v4" name="static_address" value="{{AI_IPV4}}/24"/>+
                      At the moment because only AI_NETWORK is available, so I will need an SC Profile for each network that is not a /24 That will get ugly eventually.

                      As I understand it, you want to maintain a direct mapping between AI_ variables and the network-boot-arguments key-value pairs. But if you're open the having some AI_ variables that are derived or calculated at install time there are a couple that would be nice to have.

                      AI_MASKBITS - calculate the CIDR notation mask bits from the network-boot-arguments subnet-mask, e.g.,
                      +<propval type="net_address_v4" name="static_address" value="{{AI_IPV4}}/{{AI_MASKBITS}}"/>+

                      AI_IPV4CIDR - even nicer - network-boot-arguments host-ip, slash, CIDR maskbits calculated from network-boot-arguments subnet-mask, e.g.,
                      +<propval type="net_address_v4" name="static_address" value="{{AI_IPV4CIDR}}"/>+

                      Edited by: user1077157 on Dec 5, 2012 10:14 PM
                      • 8. Re: Using SC Profile Templates - {{AI_HOSTNAME}} variable not being used
                        Dave Miner-Oracle
                        You may find that you'll get better results by generating your configuration profile as part of an AI Derived Manifests script. This is possible beginning with 11.1 as we fixed some issues that got in the way of generating the configuration profile as well. With that approach you have complete ability to look at the environment of the AI client, calculate values you want, etc. and generate exactly the configuration you desire If you would like expansions to the templating capability itself, please ask support to file enhancement requests.
                        • 9. Re: Using SC Profile Templates - {{AI_HOSTNAME}} variable not being used
                          Hi Dave,

                          That's interesting news that there were some AI Derived Manifest fixes. I tried that a few months back when we were still on Solaris 11. It didn't work quite right for me with SC profiles at the time so I gave up. Time to revisit.

                          The Support people frequently advise me to consult https://forums.oracle.com when I create an SR that isn't a clear cut break/fix case. Every time I create an SR I swear to myself that it will be the last time because it wastes a lot of time trying to convince Support that a bug exists or to create an enhancement request. They seem to be very focused on "here is the work around, let me close this SR".