I've pushed some minor but pedantic changes to v3, which will be in 3.0.9. The changes solve issues whereby people use attributes in "unlang", but they aren't picked up as attributes. Let me give an example for an unknown attribute "Foo-Bar": if (Foo-Bar == "stuff") { In 3.0.8 and earlier, the server sees this, and decides that "Foo-Bar" is just a string. It optimizes the comparison to "false", because the string "Foo-Bar" is not the same as the string "stuff". This optimization works in most situations. Where that optimization fails is for dynamic comparisons, such as SQL-Group or LDAP-Group. Therefore, as of 3.0.9, the server does more sanity checks on the left hand side of a comparison. If it's not a string such as "foo" or 'bar', but instead is just Foo-Bar, AND it looks like an attribute name, then the server assumes it's an attribute name. If no module defines the attribute, the server refuses to start, with an "unknown attribute" error. This change should have little or no effect for most people. Most of the time the text looks like an attribute name, because it is an attribute name, and the admin wants to use it as an attribute name. This change will only affect people who intend to do comparisons of the string "Foo-Bar" with the string "stuff". Those people can just put quotation marks around the "Foo-Bar" string. The benefit for everyone else is that typos are caught. e.g. if you do the following, 3.0.8 will start, but not do what you expect: if (LDAP-GroupX == "sales") { There's an extra "X", where the intention was to do: if (LDAP-Group == "sales") { 3.0.9 will now complain, and say "Unknown attribute LDAP-GroupX". As part of this change, the dictionaries no longer contain definitions for LDAP-Group and SQL-Group. Those attributes are defined ONLY when the LDAP or SQL group checking is used. Those attributes SHOULD NOT be used for anything else. In fact, it's now an error to assign a value to those attributes: update control { LDAP-Group := "foo" } This will now cause a parse error. The LDAP-Group attribute checks LDAP groups. You should NOT be assigning random values to it. To be nice, the LDAP module still does LDAP group caching, which is useful. The SQL module now registers the SQL-Group check ONLY for the main "sql" module. If you instead have: sql sql2 { ... } The SQL-Group attribute will be called "sql2-SQL-Group". The LDAP module already did something similar, so this is a good idea. Comments? Alan DeKok.