Certificate Auto Enrollment from Samba

Certificate Auto Enrollment available in Samba 4.16

Certificate Auto Enrollment allows devices to enroll for certificates from Active Directory Certificate Services. As of Samba 4.16, Linux clients can now auto enroll for certificates just like a Windows client.

Samba’s Certificate Auto Enrollment uses the certmonger service to keep track of certificates. It also uses the cepces plugin to certmonger. The sscep command is also used to download the trust chain.

Certificate Auto Enrollment is compatible with both Winbind and SSSD.

Certificate Auto Enrollment is initiated using Samba’s Group Policy client, samba-gpupdate. The Samba wiki has more details on how to setup Group Policy, and how to configure Certificate Auto Enrollment.

How to write a Samba Winbind Group Policy Extension

This tutorial will explain how to write a Group Policy Extension for Samba’s Winbind. Group Policy is a delivery mechanism for distributing system settings and company policies to machines joined to an Active Directory domain. Unix/Linux machines running Samba’s Winbind can also deploy these policies. Read my previous post about which Client Side Extensions and Server Side Extensions currently exist in Winbind.

Creating the Server Side Extension

The first step to deploying Group Policy is to create a Server Side Extension (SSE). There are multiple ways to create an SSE, but here we’ll only discuss Administrative Templates (ADMX). The purpose of the SSE is to deploy policies to the SYSVOL share. Theoretically, you could manually deploy any file (even plain text) to the SYSVOL and then write a Client Side Extension that parses it, but ADMX can be read and modified by the Group Policy Management Editor, which makes administration of policies simpler.

ADMX files are simply XML files which explain to the Group Policy Management Console how to display and store a policy in the SYSVOL. AMDX files always store policies in Registry.pol files. Samba provides a mechanism for parsing these, which we’ll discuss later.

Below is a simple example of an ADMX template, and it’s corresponding ADML file.


<policyDefinitions revision="1.0" schemaVersion="1.0">
    <target prefix="fullarmor" namespace="FullArmor.Policies.98BB16AF_01EE_4D17_870D_A3311A44D6C2" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  <supersededAdm fileName="" />
  <resources minRequiredRevision="1.0" />
    <category name="CAT_3338C1DD_8A00_4273_8547_158D8B8C19E9" displayName="$(string.CAT_3338C1DD_8A00_4273_8547_158D8
B8C19E9)" />
    <category name="CAT_7D8D7DC8_5A9D_4BE1_8227_F09CDD5AFFC6" displayName="$(string.CAT_7D8D7DC8_5A9D_4BE1_8227_F09CD
      <parentCategory ref="CAT_3338C1DD_8A00_4273_8547_158D8B8C19E9" />
    <policy name="POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061" class="Machine" displayName="$(string.POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061)" explainText="$(string.POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061_Help)" presentation="$(presentation.POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061)" key="Software\Policies\Samba\Unix Settings">
      <parentCategory ref="CAT_7D8D7DC8_5A9D_4BE1_8227_F09CDD5AFFC6" />
      <supportedOn ref="windows:SUPPORTED_WindowsVista" />
        <list id="LST_2E9A4684_3C0E_415B_8FD6_D4AF68BC8AC6" key="Software\Policies\Samba\Unix Settings\Daily Scripts" valueName="Daily Scripts" />


<policyDefinitionResources revision="1.0" schemaVersion="1.0">
      <string id="CAT_3338C1DD_8A00_4273_8547_158D8B8C19E9">Samba</string>
      <string id="CAT_7D8D7DC8_5A9D_4BE1_8227_F09CDD5AFFC6">Unix Settings</string>
      <string id="POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061">Daily Scripts</string>
      <string id="POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061_Help">This policy setting allows you to execute commands, 
either local or on remote storage, daily.</string>
      <presentation id="POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061">
        <listBox refId="LST_2E9A4684_3C0E_415B_8FD6_D4AF68BC8AC6">Script and arguments</listBox>

The meaning of the various tags are explained in Microsoft’s Group Policy documentation. Before the endless documentation and confusing XML scares you away, be aware there is an easier way!

ADMX Migrator

FullArmor created the ADMX Migrator to simplify the shift for system administrators from the old ADM policy templates to ADMX. Fortunately, this tool also serves our purpose for assisting us in easily creating these templates for our SSE. Unfortunately, the tool hasn’t seen any development in the past 8 years, and wont run in Windows 10 (or any Unix/Linux platform, for that matter). I had to dredge up a Windows 7 VM in order to install and use the tool (supposedly Vista works as well, but who wants to install that?).

Creating the Administrative Template

  1. Open ADMX Migrator
  2. Right click on ADMX Templates in the left tree view, and click New Template.
  3. Give your template a name, and click OK.
  4. Right click on the new template in the left tree view, and click New Category.
  5. Give the Category a name. This name will be displayed in the Group Policy Management Editor under Administrative Templates. You can choose to nest template under an existing category, or simply add it as a new root.
    Note: You can also add sub-categories under this category. After clicking OK, right click the category you created and select New Category.
  6. Next, create your policy by right clicking on your new category, and selecting New Policy Setting.
  7. Because we’ll be applying these settings to a Linux machine, the Registry fields are mostly meaningless, but they are required. Your policies will be stored under these keys on the SYSVOL in the Registry.pol file. Choose some sensible Registry Key, such as ‘Software\Policies\Samba\Unix Settings’, and a Registry Value Name, such as ‘Daily Scripts’ (these are the values used for Samba’s cron.daily policy). The Display Name is the name that will be displayed for this policy in the Group Policy Management Editor. I usually make this the same as the Registry Value Name, but it doesn’t need to be.
  8. Select whether this policy will be applied to a Machine, a User, or to Both in the Class field. In our example, we could potentially set Both, then our Client Side Extension would need to handle both cron.daily scripts (the Machine) and also User crontab entries. Click OK for your policy to be created.
  9. Your new policy will appear in the middle list view. Highlight it, and you will see a number of tabs below for configuring the policy.
  10. Select the Values tab and set the Enabled Value Type. In this case, we’ll use String, since our cron commands will be saved to the Registry.pol as a string. In the Value field, you can set a default enabled value (this is optional).
  11. Select the Presentation tab, right click in the Elements view, and click New Element > ListBox (or a different presentation, depending on the policy). If you look at the samba.adml file from the previous section, you’ll notice that the presentationTable contains a listBox item. That’s what we’re creating here.
  12. Choose an element Label, this will be the name for the list displayed in the Group Policy Management Editor.
  13. Choose a Registry Key. This will be pre-populated with the parent Registry Key you gave when creating the policy. Append something to the key to make it unique. We’ll use ‘Software\Policies\Samba\Unix Settings\Daily Scripts’ for our cron.daily policy.
  14. Navigate to the Explain tab, and add an explanation of what this policy is and what it does. This will be displayed to users in the Group Policy Management Editor.
  15. Now right click on your template name in the left tree, and select Save As.
  16. Finally, you’ll need to deploy your new policy definition to the SYSVOL. It should be saved to the Policies\PolicyDefinitions (the Group Policy Central Store) directory. These instructions from Microsoft can assist you in setting up your Group Policy Central Store.

Creating the Client Side Extension

The Client Side Extension (CSE) is the code that will be called by Samba’s Winbind to deploy our newly created policy to a client machine. CSEs must be written in Python3, and are deployed using the register_gp_extension() and unregister_gp_extension() samba functions.

# gp_scripts_ext samba gpo policy
# Copyright (C) David Mulder <dmulder@suse.com> 2020
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

import os, re
from samba.gpclass import gp_pol_ext, register_gp_extension, \
    unregister_gp_extension, list_gp_extensions
from base64 import b64encode
from tempfile import NamedTemporaryFile
from samba import getopt as options
import optparse

intro = '''
### autogenerated by samba
# This file is generated by the gp_scripts_ext Group Policy
# Client Side Extension. To modify the contents of this file,
# modify the appropriate Group Policy objects which apply


class gp_scripts_ext(gp_pol_ext):
    def __str__(self):
        return 'Unix Settings/Scripts'

    def process_group_policy(self, deleted_gpo_list, changed_gpo_list):

        # Iterate over GPO guids and their previous settings, reverting
        # changes made by this GPO.
        for guid, settings in deleted_gpo_list:

            # Tell the Group Policy database which GPO we're working on

            if str(self) in settings:
                for attribute, script in settings[str(self)].items():
                    # Delete the applied policy
                    if os.path.exists(script):

                    # Remove the stored removal information
                    self.gp_db.delete(str(self), attribute)

            # Commit the changes to the Group Policy database

        # Iterate over GPO objects, applying new policies found in the SYSVOL
        for gpo in changed_gpo_list:
            if gpo.file_sys_path:
                reg_key = 'Software\\Policies\\Samba\\Unix Settings'
                sections = { '%s\\Daily Scripts' % reg_key : '/etc/cron.daily',
                             '%s\\Monthly Scripts' % reg_key : '/etc/cron.monthly',
                             '%s\\Weekly Scripts' % reg_key : '/etc/cron.weekly',
                             '%s\\Hourly Scripts' % reg_key : '/etc/cron.hourly' }

                # Tell the Group Policy database which GPO we're working on

                # Load the contents of the Registry.pol from the SYSVOL
                pol_file = 'MACHINE/Registry.pol'
                path = os.path.join(gpo.file_sys_path, pol_file)
                pol_conf = self.parse(path)
                if not pol_conf:

                # For each policy in the Registry.pol, apply the settings
                for e in pol_conf.entries:
                    if e.keyname in sections.keys() and e.data.strip():
                        cron_dir = sections[e.keyname]
                        attribute = '%s:%s' % (e.keyname,

                        # Check if this policy has already been applied in the
                        # Group Policy database. Skip the apply if it's already
                        # been installed.
                        old_val = self.gp_db.retrieve(str(self), attribute)

                        if not old_val:

                            # Create a temporary file and store policy in it,
                            # then move the file to the cron directory for
                            # execution.
                            with NamedTemporaryFile(prefix='gp_', mode="w+",
                                    delete=False, dir=cron_dir) as f:
                                contents = '#!/bin/sh\n%s' % intro
                                contents += '%s\n' % e.data
                                os.chmod(f.name, 0o700)

                                # Store the name of the applied file, so that
                                # we can remove it later on unapply (see the
                                # first loop in this function).
                                self.gp_db.store(str(self), attribute, f.name)

                        # Commit the changes to the Group Policy database

    def rsop(self, gpo):
        output = {}
        pol_file = 'MACHINE/Registry.pol'
        if gpo.file_sys_path:
            path = os.path.join(gpo.file_sys_path, pol_file)
            pol_conf = self.parse(path)
            if not pol_conf:
                return output
            for e in pol_conf.entries:
                key = e.keyname.split('\\')[-1]
                if key.endswith('Scripts') and e.data.strip():
                    if key not in output.keys():
                        output[key] = []
        return output

if __name__ == "__main__":
    parser = optparse.OptionParser('gp_scripts_ext.py [options]')
    sambaopts = options.SambaOptions(parser)

    parser.add_option('--register', help='Register extension to Samba',
    parser.add_option('--unregister', help='Unregister extension from Samba',

    (opts, args) = parser.parse_args()

    # We're collecting the Samba loadparm simply to find our smb.conf file
    lp = sambaopts.get_loadparm()

    # This is a random unique GUID, which identifies this CSE.
    # Any random GUID will do.
    ext_guid = '{5930022C-94FF-4ED5-A403-CFB4549DB6F0}'
    if opts.register:
        # The extension path is the location of this file. This script
        # should be executed from a permanent location.
        ext_path = os.path.realpath(__file__)
        # The machine and user parameters tell Samba whether to apply this
        # extension to the computer, to individual users, or to both.
        register_gp_extension(ext_guid, 'gp_scripts_ext', ext_path,
                              smb_conf=lp.configfile, machine=True, user=False)
    elif opts.unregister:
        # Remove the extension and do not apply policy.

    # List the currently installed Group Policy Client Side Extensions
    exts = list_gp_extensions(lp.configfile)
    for guid, data in exts.items():
        for k, v in data.items():
            print('\t%s: %s' % (k, v))

The gp_pol_ext/gp_inf_ext Python Classes

Your CSE must be a class that inherits from a subclass of gp_ext. The gp_pol_ext is a subclass of gp_ext that provides simplified parsing of Registry.pol files. If you choose to store your policies in ini/inf files in the SYSVOL (instead of using Administrative Templates), then you can inherit from the gp_inf_ext instead.

If your class inherits from either gp_pol_ext or gp_inf_ext, it has a parse() function defined, which takes a single filename. The parse() function will parse the contents of the policy file and return it in a sensible format.

If for some reason you choose to store data on the SYSVOL in some other format (such as in XML, etc), you’ll need to subclass gp_ext, then implement a read() function, like this:

import xml.etree.ElementTree
class gp_xml_ext(gp_ext):
    def read(self, data_file):
        return xml.etree.ElementTree.parse(data_file)

The read() function is called by parse(), passing it a local filename tied to the systems SYSVOL cache. Then within process_group_policy() you can call parse() to fetch the parsed data from the SYSVOL.

Process Group Policy

The process_group_policy() function serves two primary purposes; it applies new policy, and it removes old policy. In the example, you’ll notice there are two main loops. The first loop iterates over the deleted_gpo_list, which are all the policies that should be removed. The second loop iterates over the changed_gpo_list, which are new policies which must be applied.

Deleted GPOs

for guid, settings in deleted_gpo_list:
    if str(self) in settings:
        for attribute, script in settings[str(self)].items():
            if os.path.exists(script):
            self.gp_db.delete(str(self), attribute)

The deleted_gpo_list is a dictionary which contains the guids of Group Policy Objects, with associated settings which were previously applied. This list of applied settings is generated by the second loop (changed_gpo_list) while it is applying policy. The self.gp_db object is a database handle which allows you to manipulate the Group Policy Database.

The Group Policy Database keeps track of all settings that have been applied, and info on how to revert those applied settings. For example, in the smb.conf CSE, the attribute stored in settings could be client max protocol and the stored value could be NT1. If our GPO has applied a client max protocol set to SMB3_11, the Group Policy database keeps track of the previous value of NT1 for when it’s time to remove the SMB3_11 policy.

In our example cron script policy above, you can see that the stored value is a filename (the script variable). This is actually the name of the script we’ve applied, which will allow us to delete it later (therefore removing the policy). The scripts CSE is a special case, where we don’t need to keep track of an old value to restore, instead we’re keeping track of files to delete (since the ‘old value’ is that the script didn’t exist).

Changed GPOs

for gpo in changed_gpo_list:
    if gpo.file_sys_path:
        reg_key = 'Software\\Policies\\Samba\\Unix Settings'
        sections = { '%s\\Daily Scripts' % reg_key : '/etc/cron.daily',
                     '%s\\Monthly Scripts' % reg_key : '/etc/cron.monthly',
                     '%s\\Weekly Scripts' % reg_key : '/etc/cron.weekly',
                     '%s\\Hourly Scripts' % reg_key : '/etc/cron.hourly' }
        pol_file = 'MACHINE/Registry.pol'
        path = os.path.join(gpo.file_sys_path, pol_file)
        pol_conf = self.parse(path)
        if not pol_conf:
        for e in pol_conf.entries:
            if e.keyname in sections.keys() and e.data.strip():
                cron_dir = sections[e.keyname]
                attribute = '%s:%s' % (e.keyname,
                old_val = self.gp_db.retrieve(str(self), attribute)
                if not old_val:
                    with NamedTemporaryFile(prefix='gp_', mode="w+",
                            delete=False, dir=cron_dir) as f:
                        contents = '#!/bin/sh\n%s' % intro 
                        contents += '%s\n' % e.data
                        os.chmod(f.name, 0o700)
                        self.gp_db.store(str(self), attribute, f.name) 

The second loop is a little more involved. When we iterate over changed_gpo_list, we’re actually iterating over a list of GPO objects. The attributes of the object are:

  • gpo.name: The GUID of the GPO.
  • gpo.file_sys_path: A physical path to a cache of GPO on the local filesystem.

There are other methods and attributes, but these are the only ones important to a CSE.

The primary purpose of this loop is to iterate over the GPOs, read their policy in the SYSVOL, then check the sections for the Registry Key we created in our Server Side Extension. If our policy Registry Key exists, then we read the entry and apply the policy.

In our example, we find the ‘Software\Policies\Samba\Unix Settings\Daily Scripts’ policy, then read the script contents from Registry.pol entry and write the script to a local file. In the example code, we write the script to a temporary file, then move the file to it’s permanent location in /etc/cron.daily.

We also have to make sure we set the name of the new script in our self.gp_db (Group Policy Database). This ensures that we can remove the policy when we delete the GPO. At the beginning of our loop, we also need to ensure we call set_guid() on our Group Policy Database, so it knows which GPO we’re operating on.

Resultant Set of Policy

The rsop() function in the extension is optional. It should return a dictionary containing key/value pairs of what our current policy will or has applied. The function is passed a list of GPO objects (similar to our changed_gpo_list), and we should parse the list similar to how we did in our changed_gpo_list loop. The difference is that the rsop() function does not apply any policy. It only returns what will be applied. This function enables the samba-gpupdate --rsop command to report on applied, or soon to be applied policy.

Registering/Unregistering a Client Side Extension

The final step is to register an extension on the host. While the example code provides a detailed example of how to register an extension, the basic requirement is simply to call register_gp_extension().

ext_guid = '{5930022C-94FF-4ED5-A403-CFB4549DB6F0}'
ext_path = os.path.realpath(__file__)
register_gp_extension(ext_guid, 'gp_scripts_ext', ext_path,
    smb_conf='/etc/samba/smb.conf', machine=True, user=False)

The extension guid can be any random guid. It simply must be unique among all extensions that you register to the host. The extension path is literally just the path to the source file containing your CSE.

You must pass your smb.conf file to the extension, so it knows where to store the list of registered extensions. You also must specify whether to apply this extension to the machine, or to individual users (or to both).

Unregistering the extension is simple. You call the unregister_gp_extension() and pass it the unique guid you previously chose which represents this CSE.


I hope this tutorial proves useful. Please comment below if you have questions! You can also reach me on freenode in the samba-technical channel (nic: dmulder).

Samba Winbind Group Policy

Samba version 4.14 will ship with Group Policy for Winbind. The Group Policy offerings are made to be similar to what is offered by proprietary tools, such as Vintela’s and Centrify’s Group Policy.

Group Policy Management Console

Winbind Group Policy provides the ability to distribute smb.conf settings, Sudo Privileges, Message of the Day and Login Prompt messages, and daily, hourly, monthly, or weekly cron jobs.

To enable Group Policy in Winbind, set the apply group policies global smb.conf option to Yes. You can even deploy this setting from Group Policy smb.conf options, then running the apply command manually the first time with sudo samba-gpupate --force.

In order to use the Samba Administrative Templates in the Group Policy Management Console, you’ll need to install them first, using the command sudo samba-tool gpo admxload -UAdministrator. This will upload the samba.admx template to the joined domains SYSVOL share.

Resultant Set of Policy

To see what policies will apply to a machine before applying them (or to view what policies are already applied), run the command sudo samba-gpupdate --rsop.

linux-h7xz:~ # samba-gpupdate --rsop
Resultant Set of Policy
Computer Policy

GPO: Default Domain Policy
  CSE: gp_sec_ext
  CSE: gp_sec_ext
  CSE: gp_scripts_ext
  CSE: gp_sudoers_ext
    Policy Type: Sudo Rights
    [ tux ALL=(ALL) NOPASSWD: ALL ]
  CSE: gp_smb_conf_ext
    Policy Type: smb.conf
    [ apply group policies ] = 1
    [ client max protocol ] = SMB2_02
  CSE: gp_msgs_ext
    Policy Type: /etc/motd
This message is distributed by Samba!
    Policy Type: /etc/issue
Samba Group Policy \s \r \l

smb.conf Policies

smb.conf policies are found in Computer Configuration > Policies > Administrative Templates > Samba > smb.conf. These policies distribute smb.conf global options to the client. This policy is unable to apply idmap policies.

Password and Kerberos Policies

Password and Kerberos policies, found in Computer Configuration > Policies > OS Settings > Security Settings > Account Policy, are only applicable to Samba Domain Controllers.

The following password policies are applicable:

  • Minimum password age
  • Maximum password age
  • Minimum password length
  • Password must meet complexity requirements

And Kerberos policies:

  • Maximum ticket age (Maximum lifetime for user ticket)
  • Maximum service age (Maximum lifetime for service ticket)
  • Maximum renew age (Maximum lifetime for user ticket renewal)

Script Policies

Script policies create cron jobs on client machines which execute the specified commands. Script policies are found in Computer Configuration > Policies > Administrative Templates > Samba > Unix Settings > Scripts.

To add a script policy, open the policy, enable it, and click Show. In the dialog that appears, add the command to execute on the client. Click OK, then Apply to save the policy.

Applying a Daily cron job

Script policies are applied as cron jobs on the winbind client.

linux-h7xz:~ # /usr/sbin/samba-gpupdate --force
linux-h7xz:~ # cat /etc/cron.daily/tmp6l0m809i 
whoami > /daily.log

Sudoers Policies

Sudoers policies add sudo rules to client machines. Sudoers policies are found in Computer Configuration > Policies > Administrative Templates > Samba > Unix Settings > Sudo Rights.

To add a sudo policy, open the policy, enable it, and click Show. In the dialog that appears, add the sudo rules to the list. Click OK, then Apply to save the policy.

linux-h7xz:~ # /usr/sbin/samba-gpupdate --force
linux-h7xz:~ # cat /etc/sudoers.d/gp_eockoryg

### autogenerated by samba
# This file is generated by the gp_sudoers_ext Group Policy
# Client Side Extension. To modify the contents of this file,
# modify the appropriate Group Policy objects which apply


Message Policies

Message policies set the contents of the /etc/motd and /etc/issue files on client machines. Message policies are found in Computer Configuration > Policies > Administrative Templates > Samba > Unix Settings > Messages.

To add a message of the day policy, for example, open the policy and enable it. In the text box provided, enter the message you’d like displayed after a successful login.

linux-h7xz:~ # samba-gpupdate
linux-h7xz:~ # cat /etc/motd
This message is distributed by Samba!

To add a login prompt policy, open the ‘Logon Prompt Message’ policy and enable it. In the text box provided, enter the message you’d like displayed before the login prompt. You can use escape sequences supported by the client /etc/issue file.

linux-h7xz:~ # samba-gpupdate
linux-h7xz:~ # cat /etc/issue
Samba Group Policy \s \r \l

For more information about Winbind Group Policy, see the Samba wiki.

Deploying Samba smb.conf via Group Policy

I’ve been working on Group Policy deployment in Samba. Samba master (not released) currently now installs a samba-gpupdate script, which works similar to gpupdate on Windows (currently in master it defaults to –force, but that changes soon).
Group Policy can also apply automatically by setting the smb.conf option ‘apply group policies’ to yes.
Recently, I’ve written a client side extension (CSE) which applies samba smb.conf settings to client machines. I’ve also written a script which generates admx files for deploying those settings via the Group Policy Management Console.

You can view the source, and follow my progress here: https://gitlab.com/samba-team/samba/merge_requests/32

Group Policy Management Console for Linux

I’m working on a YaST module that imitates the behavior of the Group Policy Management Console in linux.

You can install it on openSUSE Tumbleweed via:
sudo zypper in yast2-python-bindings
sudo zypper ar https://download.opensuse.org/repositories/network:/samba:/STABLE/openSUSE_Tumbleweed/ samba
sudo zypper ref && sudo zypper in yast-gpmc

Then run it with:
yast2 gpmc

It requires yast2-python-bindings version 4.0+, which is only available in openSUSE Tumbleweed at the moment (although it’ll be in the next version of SLE).

YaST and Python, the new bindings

YaST has had python bindings for about 10 years, but there has been no maintainer for the last 4 years, and they’ve slowly gone kaput.

That has changed. Python+YaST is back. The syntax is (or should be) backwards compatible with <= 3.x of the yast-python-bindings, but you can now write python yast via code very similar to the ruby code.
There are also lots of examples now (thanks to noelp and his hackweek project).

We’re working on a couple of yast modules via the yast-python-bindings:

vSphere Client on openSUSE 42.2

I needed vSphere client on linux, but vmware only builds a Windows version. Here is my work-around:

First, install vSphere Client via wine. I personally used vSphere Client (and server) 5.1.

WINEARCH=win32 WINEPREFIX=$HOME/.vmware-client ./winetricks msxml3 dotnet35sp1 vcrun2005 vcrun2008 vcrun2010
WINEARCH=win32 WINEPREFIX=$HOME/.vmware-client wine VMware-viclient-all-5.1.0-2306356.exe
When you get the hcmon install failure, copy the entire contents of your wine bottle to a tmp directory, complete the installation (says it failed), then mv the contents back.
cp $HOME/.vmware-client $HOME/.vmware-client2

rm -rf $HOME/.vmware-client
mv $HOME/.vmware-client2 $HOME/.vmware-client

Now you can run the vSphere Client with:
WINEARCH=win32 WINEPREFIX=$HOME/.vmware-client wine ~/.vmware-client/drive_c/Program Files/VMware/Infrastructure/Virtual Infrastructure Client/Launcher/VpxClient.exe

The biggest drawback is that the console doesn’t work, so install VMware Remote Console.
The remote console can connect to a vSphere server and provide the console functionality that’s broken in the client. Just provide it the host url, username, etc on the command line:

> /usr/bin/vmrc –help
vmrc [OPTION…]

Help Options:
-h, –help Show help options

Application Options:
-v, –version Display the program version
-X, –fullscreen Start in fullscreen mode
-M, –moid=moid A managed object id indicating the VM to connect to
-U, –user=username Username used to authenticate to the remote host
-P, –password=password Password used to authenticate to the remote host
-D, –datacenter=datacenter Datacenter containing the VM to open
-H, –host=host:port Remote host containing VMs you wish to access


Authors: David Mulder, Curtis Welborn


This paper describes the implementation of a garbage collector as an undergraduate research project. The garbage collector is a continuation of a project where an Assembler, Virtual Machine and Compiler were implemented as a capstone project. The project required modifying the compiler to allocate memory compatible with a mark and sweep algorithm, and adding the mark and sweep algorithm to the virtual machine. Computer Science faculty should take note that this was all completed by an undergraduate student within a year’s time, and that such challenges can reasonably be accomplished by undergraduate seniors.


Challenges of the nature described in this paper are generally reserved for graduate students, and are considered outside the grasp of undergraduates. Computer Science faculty and students alike will be interested to note that the preceding project was completed entirely by an undergraduate senior. It is also interesting to note that the project was completed by an average student of little academic achievement, and that a Compiler, Assembler and Multi-Processed Virtual Machine with Garbage Collection were written within a year’s time.

As part of an undergraduate capstone, an Assembler, Virtual Machine and Compiler were implemented. The two-pass Compiler performs Lexical and Syntax analysis in the first pass, and Semantic analysis and Intermediate code generation in the second pass. Using Intermediate code as input, the Compiler then generates target code (assembly) that can be fed to the Assembler to generate byte-code. The byte-code can then be loaded into the Virtual Machine for execution [1]. Through independent study, a garbage collector was added to the virtual machine, which included extensive changes to the compiler.

The compiler had to be modified to place by-reference parameters onto the run-time stack first. An additional parameter is also added that counts the number of by-reference parameters. The counter is needed by the Mark and Sweep algorithm to determine the location of the by-reference parameters within an Activation Record.

To support the mark and sweep garbage collection algorithm, the virtual machine had to be modified to allocate memory from a list of available blocks. The mark and sweep algorithm is triggered when a call to allocate memory detects no free blocks. In the mark phase of the algorithm, the run-time stack is traversed searching for points that reference blocks allocated on the heap. Any block of memory reachable from the run-time stack must be marked as in use. During the sweep phase of the algorithm, the heap is searched looking for any blocks not marked as in use during the mark phase.
Screenshot from 2015-10-09 13:18:55


The compiler was originally written to pass parameters to a function call via an activation record in the order they were written in the source language (a language called KXI, which is similar to java). It was necessary for the compiler to segregate between by-reference and by-value parameters. The mark phase of the algorithm must know the location of every by-reference parameter within a function calls’ activation record. See the ordering of variables in the current Activation Record of Figure 1. Because the variables are segregated, references are easily located based on offsets. For example, the first reference is located by an offset of 4*sizeof(int) from the base of the activation record (the return address, previous activation record pointer and reference counters are all integers), and the second reference is offset 5*sizeof(int) from the base.

The mark phase of the algorithm needed a special field inserted in each activation record that counts the number of by-reference parameters. This field was added in the activation record in such a way that the mark phase could iterate over each by-reference parameter and set the mark bit in the corresponding block for each object allocated on the heap. The field is referred to as the Reference Counter in Figure 1. The reference counter in this activation record tells us that there are 2 references. If we decremented the reference counter to 1, for example, the second reference on the stack would be interpreted as an integer.


In order to make space allocation more efficient, the heap was separated into large and small blocks. Bit vectors were used to keep track of which blocks are allocated on the heap.

An instruction was added to the virtual machine for allocating memory. Prior to the instruction, memory allocation consisted of just moving a pointer within the heap. The new allocation instruction calls the mark and sweep algorithm. If there is space available on the heap, the instruction returns a pointer to that block and marks the block as unavailable within one of the vectors that tracks all blocks in the heap.

If no available space is found, garbage collection is started. The algorithm must calculate the location of the activation record for the current function call then calculates the offset to the by-reference counter field in the activation record. Now having the number of pass by-references parameters in the current activation record, the algorithm can calculate the offset to each allocated block on the heap and set its mark bit to in use.

The algorithm must recursively follow references allocated inside of each block. This was achieved by organizing objects within a block in a similar manner to how function calls are organized in an activation record. In this way, lists, trees and even recursive data structures allocated on the heap can all be traversed and marked. In Figure 1, the mark phase will follow all references inside of Small Block A, so Small Block B is also marked.

Once all objects (blocks) and descendant objects have been marked, the algorithm calculates the location of the previous activation record. The same process of following references and marking objects proceeds for each activation record until all function calls on the run-time stack have been searched.

The sweep phase of the algorithm now iterates over the entire heap, checking the mark bit. If the mark bit is set (the block is in use), it clears the bit and moves on. This means that the block has a live reference to it which originated in an activation record that is currently on the run-time stack. Blocks A, B and D in Figure 1 have references pointing to them. These blocks will be un-marked and will remain allocated.

If the mark bit is not set, the algorithm clears the relevant marker in the vector of available blocks, freeing the block for reuse (See Small Block C in Figure 1) [2]. This allocated block will be freed during the sweep phase because it has no references pointing to it on the run-time stack.


This method of garbage collection is effective, but did prove to be inefficient. Because the algorithm isn’t activated until there is no remaining free space, the algorithm isn’t suitable for real time applications. The algorithm could be modified to operate incrementally, but it would still cause an occasional lag. These are known problems of garbage collection.

The greatest achievement of this project was the recognition of what can be accomplished by undergraduate seniors. Computer Science faculty should recognize that computing projects of this caliber can reasonably be expected in an undergraduate senior project course.


The primary author has started work on an hp-ux pa-risc virtual machine. The first obstacle will be setting up the correct environment, based on descriptions in the pa-risc specifications. The second will be translating the pseudo code in the specification into C. A compiler/translator will be written to automatically convert the specification pseudo code into C.

A significant part of the project will be writing the loader, since it will need to include things such as run time linking. Ideally, the virtual machine will run at boot time and will include a boot loader. This would allow pa-risc software to run on virtually any hardware.


[1] Mulder, D., Welborn, C., Lessons in converting from python to c++, Journal of Computing Sciences in Colleges, 29(2), 49-57, December 2013, http://dl.acm.org/citation.cfm?id=253542
[2] Jones, R., Lins, R. D., Garbage collection: Algorithms for automatic dynamic memory management, West Sussex, England

© CCSC, (2014). This is the author’s version of the work. It is posted here by permission of CCSC for your personal use. Not for redistribution. The definitive version was published in The Journal of Computing Sciences in Colleges, {volume 30, number 2, December 2014}, http://dl.acm.org/.

Deploying Configuration Profiles in OSX using QAS Group Policy

Here’s an alternative to applying Configuration Profiles in OSX without using an MDM client. Profiles are deployed using Group Policy over SMB, so you don’t have to open APN ports to Apple.
QAS is an AD bridge tool for unix/linux systems (including mac) that also provides Group Policy support. You can view more details here.

QAS Group Policy lets you specify Group Policy settings inside the Group Policy Management Editor, the same way you’d apply settings for a Windows host.
Screenshot from 2015-10-08 14:48:40It works similar to Apple’s Profile Manager.

Screenshot from 2015-10-08 14:54:54

You can also create custom profiles by writing preference manifests. The preference manifests are converted to Configuration Profiles before they’re applied on the OSX host.

On the OSX host, settings are retrieved from Group Policy, and installed as Configuration Profiles.

Screenshot from 2015-10-08 15:22:01