Monthly Archives: November 2012

Xmas Time Is Here – You can now RENAME!! Global Objects in MDS

Oh you are going to love this one. Direct from the horses mouth…Ofer Barzvi


Hello Michael,


I would like to inform you that this RFE was added in R75.40VS and you can start using it by setting the environment variable MDS_ALLOW_RENAME_GOBJECTS to 1 (and restarting the mds from the shell in which variable was set).


Starting from next major release after R75.40VS, the ability will be enabled by default and there will be no need to use the environment variable.

Thanks you for your input, Ofer



And get this. It works! The environmental variable was a kludge, they only changed the name and not the underlying references so it broke everything. In the next releases they will actually make both the names and references work together.

I know, I’m a great guy, You Don’t Have To Tell Me.

Take the credit, spread the blame,


The Long Road to RADIUS Configuration of Firewalls

UPDATE: 5/13/2014

I found a feature/design flaw/bug/workaround in how the firewall identifies itself to the RADIUS server.

RADIUS server receives 3 IP addresses from the RADIUS client

  1. RAS IP: IP of the firewall interface that is making the request to the RADIUS server
  2. NAS IP: Alias IP of the firewall generally used for RADIUS accounting
  3. CLIENT IP: of the remote desktop client trying to SSH or WEBUI to the firewall



Problem: Seems that some RADIUS servers use the NAS-IP to do their database lookup for AV pairs, instead of the RAS IP. More specifically RADIUS uses the RAS IP for secret key lookup and NAS IP for AV pairs. Go figure.

The NAS IP is set in your /etc/hosts file for the localhost and the local host DNS name. You can also set this in your WEBUI


Its fixed in R77.10 a bit:



UPDATE: 2/18/2014

I spoke with the developers on this and got more info:

  1. R77 (I am at R75.47) you can specify a default shell of /bin/bash instead of /bin/clish and then EVERYONE who is RADIUS authenticated will go into /bin/bash and not clish. So this is what SPLAT had which is nice we are finally back to where we started.
  2. I asked the developer to consider adding another Radius Attribute GAIA-user-shell, where in RADIUS you can set the shell to /bin/bash or /bin/clish for that user. He thought it was a good idea and would consider it.
  3. gaia-superuser-access attribute RADIUS attribute is used to assign a Unix UID of 0 for superuser or 96 for regular user. I haven’t seen this documented anywhere and haven’t tried it to verify.
  4. Note: The role ‘radius-group-any’ gets assigned to EVERY user by default. So if a user has a role ‘guionlyRole’, the user will get the guidonlyRole features as well as the features from ‘radius-group-any’. I haven’t see this documented anywhere.
  5. Make sure you have
    hotfix HOTFIX_FOXX_HF_HA46_074
    as well as these. They are for the super user setting UID to 0:For pam rpm, command is a little different. Do:
    rpm -Uvh –force –noscripts pam-
    For CPshell, normal command:
    rpm -Uvh –force CPshell-1-986008001.i386.rpm

UPDATE:  02/5/2014
I got some of it to work on R75.46 with hotfix HOTFIX_FOXX_HF_HA46_074

I setup my own FreeRadius server (it was easy) and customized it according to sk72940 and it looks like it works.


  1. All users defined on RADIUS server. (Trying to get this to proxy to AD will be next step).
  2. Here is the RADIUS dictionary and the user definition for user ‘radius1’.usersfile
  3. No users defined locally on GAIA
  4. So now I SSH onto system and you can see the attributes being passed back to GAIA
    radius debug
  5. Now I log into expert mode and check out my security context. SuperUser!
  6. Here is the /var/log/messages file should look like:
  7. Network sniff should look like thisadminrole2
  8. FYI: I can’t seem to get CP_Gaia-SuperUser-Access=0 to do anything. I can’t log in with it.
    I can modify the CP-Gaia-user-Role and it will change the role for the user. For example,
    I can change CP-Gaia-user-Role=monitorRole and user will have read-only access and
    cannot! execute the expert command.

I just wish we could go directly into Unix mode and not have to use the expert password. Why? If someone quits we still have to change the expert password on 1000000000 of firewalls. SO how about this?

If you add a the user to GAIA as UID 0:


and set the shell to bash




and then make ‘radiusroot’ to exist in your AD/RADIUS server, …abra cadabra…. you are notw AD authenticated into /bin/bash! Unfortunately this means you have to add bash users to all 1000000 firewalls you own.

Oh well, beggers can’t be choosers I guess.

I’ll let you know if I can get AD proxy going. Stay tuned!

Get your RADIUS on!


UPDATE: 10/23/2013

Last I heard is there is a fix to give RADIUS users either bash or clish, but not both. Haven’t tried it.

The Fix.

UPDATE: 4/21/2013

So spoke with someone in the know and got same info:
There is no way they know of to RADIUS authenticate into expert mode. They claim R&D is going to fix it, but our person rolled their eyes.
So the status is RADIUS users can now execute tcpdump. So you can build a ‘netdebug’ group in GAIA and give them limited access.
But for the superadmins, you still either have to:
   1) Create each person individually on the firewall UID 0 and then RADIUS auth them into /bin/bash
   2) Create a generic account UID 0 on each firewall and then RADIUS auth them into /bin/bash
Hope this saves you some work,


3/29/2013: Word from R&D is that Radius authenticated users cannot be assigned UID 0, so they will not be able to execute commands like tcpdump. This is a design decision.  My opinion is this is a bad bad bad decision. It goes backwards from SPLAT. You can’t globally manage a disparate set of administrators.

They have updated the RADIUS groups to allow RADIUS attributes so you can have more than 1 security group, but in the end you still have to hand out the expert password to get UID 0 access. How lame is that?  Obviously R&D never tried changing expert passwords on 500 firewalls when an admin leaves.

UPDATE:: 1/21/2013: Ask and you shall receive:

BUT: still have to specify virtual systems assigned to role.


In large environments were many administrators have CLI access, GAIA was designed to provide a fine grain level of control over those users with ‘roles’.  GAIA was like the uber-cpshell. You could have 1 group be superusers, 1 group be run-backups admins, 1 group be tcpdump type admins, 1 group be, etc.

Unless you use RADIUS.

If non-local users are RADIUS authenticated, then they are put into one GAIA role ‘radius-group-any’. Now you can custom design what this group does. For example:

add rba role radius-group-any domain-type System readonly-features arp, ext_ping ,ext_traceroute

So this group only does arp, ping, traceroute

BUT, now there is only ONE RADIUS group that can only do ONE set of things.

Hopefully! this will be fixed soon. I’m trying to figure out how to get around this.

Unfortunately it only gets better under VSX.

When you create a role, you can assign the VSs that it can operate in (which is undocumented)

add rba role  ROLENAME virtual-system-access 0,1,2,3,4,5,………………

Well, seems OK unless you have 250 VSs on several clusters and have several different roles. Can you say exponential problem?

You cannot say

add rba role  ROLENAME virtual-system-access all

which is what the adminrole is:

domain-type applies to all domains
virtual-system access: all

No, you have to go through and add each VS to each role one at a time……UGH. Another RFE.

add rba role  ROLENAME virtual-system-access 0,1,2,3,4,5,6,7,8,9…………


Peace Out



NTP has changed on GAIA. SPLAT had its own convoluted cpd_sched daemon to schedule NTP polls. GAIA is using the normal Linux NTPD daemon to do its work. Thank you!

If you need to dink around with NTP, you use the standard Unix commands:

ntpdate -u <IP address> # force a sync
ntpq -pn # displays the poll times in seconds, if all columns are ‘0’ you are not syncing

NOTE that if you dink with /etc/ntp.conf, you better write protect it so GAIA does not overwrite it when it boots.

Now to reset the ntp poll times, you can still use

# set to 1 hour 3600 seconds

ntp -n 3600

and a file will be created in /etc/sysconfig/ntp that contains this config into. This file survives reboots and is used to reset the NTPd parameters. This command will enter the ‘ntpdate’ command into the cpd_sched_config list to run every 3600 seconds and poll for NTP time.

Helen's Loom

"Peculiar travel suggestions are dancing lessons from God." - Kurt Vonnegut

Life Stories from Dreez

These are stories from my travels. Generally I like to write stories about local people that I meet and also brag about living the retirement dream with my #1 wife Gaby. She is also my only wife.