forum.opsi.org

Hi,

I am keen to implement an opsi solution on my server running CentOS 6. The problem is Samba. Opsi uses Samba, and the opsi-depotserver RPM has been built with samba (ie Samba3) as a dependency. But I already have a working installation of Samba4 with AD setup and running. I do NOT want Samba3. So, my questions are:

1. How do I get around the opsi installation dependency problem? One idea I had was to download the source RPM of opsi-depotserver and rebuild it after editing the spec file to delete 'samba' from the 'requires' section. It seems I would also have to delete the scripts from the 'pre' and maybe 'post' sections that add users, groups, etc. Any advice from the developers or someone who may have done this would be appreciated.

2. Assuming that item 1 is feasible, the setup of Samba4 with opsi would then be done manually. Any instruction on this would also be helpful.

In my experience, creating a RPM package with something like Samba as a dependency is bad practice because it just creates headaches. Samba is a complex package in its own right, with many options and different ways of setting it up. It would be better to exclude it from the dependency list and just instruct users in the documentation that they must install Samba if not already. Then provide instructions to add user account(s), file shares, etc. for opsi. This avoids dependency issues and also gives the administrator more flexibility in the setup.

Regards,

Stephen Jones

Hi,

for debian/ubuntu we build an package
opsi-depotserver-expert
without dependencies to samba. I am not sure, why this package is missing for CentOS, we will have a look at this in the next days.

Anyway the default user pcpatch:pcpatch , opsiconfd has to be modified similar to the notes on ucs3 in http://download.uib.de/opsi4.0/doc/html ... n-base-ucs for working with samba4.

regards,
Bardo Wolf

Hi,

Thanks for your reply. Do you know when the opsi-depotserver-expert package for CentOS might be available?

I read the notes on UCS and, while it provides some information, it is rather UCS-specific and therefore not entirely helpful. There are still blanks to fill in.

In the meantime I have been playing around with the demo VM version, which has been far more troublesome than I expected. I may write a separate post on that. It has given me a better idea of how opsi works and what may need to be changed to integrate with Samba4.

This is what I understand from the documentation and observation:
1. The user pcpatch changes from a unix account to an AD user account (Domain Users).
2. The group pcpatch changes from a unix group to an AD group with name opsifileadmins. User pcpatch is added to this group.
3. The user opsiconfd remains as a unix system account.

These things are unclear:
1. System user opsiconfd is created during the install with its primary group as pcpatch, which no longer exists. What is the primary group for opsiconfd? Can it be opsifileadmins - an AD group?
2. What happens with the group opsiadmin and user adminuser? Both adminuser and opsiconfd are members of the opsiadmin group.

I have also been looking through the code of the opsi-setup program, wondering what aspects should or should not be used in this scenario. Obviously avoid using the auto-configure-samba option. Samba4 AD must be setup manually and ACLs defined. What about the set-rights option that sets file ownership and permissions? Will this work successfully with Samba4 AD? If not, what would you suggest?

Any guidance would be appreciated.

Regards,

Stephen Jones

Hi,

lloydsystems hat geschrieben:Hi,

Do you know when the opsi-depotserver-expert package for CentOS might be available?

We are working on it, but I'm sorry cause I can not say, when it will be available.

Another way around might be, if you build a dummy samba-rpm or build a samba4-package with provides the required dependency

Regarding your samba4 questions:

On ucs3

1. The user pcpatch changes from a unix account to an AD user account (but is not member of (Domain Users)).
2. The user opsiconfd changes from a unix account to an AD user account (but is not member of (Domain Users))
3. The group pcpatch changes from a unix group to an AD group with name opsifileadmins. User pcpatch and opsiconfd members of this group.

Adminusers should be members of opsifileadmins.

Actually we are testing the debian-package opsi-depotserver-expert with the SerNet Samba 4 Appliance 0.6 but not finished at the moment.

In my testserver here is a problem regarding and therefore

the default acl.conf in /etc/opsi/backendManager is not working. We are in contact with samba4 people to solve this issue, which might be a misconfiguration of winbind.

May be end of next week we have more info which we could share

regards,
Bardo Wolf

Hi,

Creating a dummy samba RPM does not entirely solve the problem. It would satisfy the dependency of opsi-depotserver, allowing it to install, but the install routine runs code to create unix/samba users and groups. For example, unix user and group pcptch rather than AD user pcpatch and group opsifileadmins.

My preferred workaround would be to just build the opsi-depotserver-expert RPM with samba removed from the dependencies. To do this I would:
1. Download the source RPM of opsi-depotserver and install in build environment
2. Rename the spec file to opsi-depotserver-expert and edit
3. Change the package name, remove samba from 'requires', edit 'confilicts'
4. Remove code manipulating users/groups from the %pre, %post and %postun sections
5. Extra - I would also replace /opt/pcbin/install with /var/lib/opsi/depot
6. Build the RPM

This is not difficult. The opsi-depotserver package, other than creating users/groups, only makes a few directories and installs opsi-setup. The hard part is working out what to do afterwards in resolving users/groups, file ownership/permissions/ACLs, and potential issues with opsi-setup in a Samba4 AD environment rather than Samba3. This, I imagine, is what you guys are looking at too.

Sorry if I'm asking the same question again, but I'm confused by your comment that opsiconfd changes to an AD account. opsiconfd is the account running the daemon so I thought it would remain a local system account, and there is nothing in the document that says it changes. Is there a reason it must be an AD user? Also you say adminusers should be members of opsifileadmins, but what about the group opsiadmins? The code in opsi-setup is still looking for group opsiadmins.

You mention you have a problem with 'getent group opsifileadmins'. As opsifileadmins is an AD group, getent will not return anything unless /etc/nsswitch.conf is modified to use winbind thus:
passwd: files winbind
group: files winbind

Then 'getent group' will return AD groups, but won't show the group members. Maybe this is your problem. I believe this behaviour is intentional. It is certainly this way on my CentOS 6 Samba4 server. I have seen examples where getent does show AD group membership, but only with older Samba3. If it's any help Samba4 can return AD group membership with: I have also noticed that pcpatch uses SSH access to the depot server. I should point out that, if pcpatch moves to an AD user, this will not work without modification to PAM and Samba. pcpatch can use kerberos or winbind to authenticate SSH. On RHEL/CentOS 6 this means editing /etc/pam.d/password-auth (on version 5 I think it was system-auth - check which file is included by /etc/pam.d/sshd). password-auth is actually a symlink to password-auth-ac, controlled by authconfig, so better to make a new file password-auth-local and change the link. The edited file should contain pam_krb5 and/or pam_winbind where shown:

auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_krb5.so use_first_pass
auth sufficient /lib/security/pam_winbind.so use_first_pass
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account sufficient pam_krb5.so
account sufficient /lib/security/pam_winbind.so
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_krb5.so use_authtok
password sufficient /lib/security/pam_winbind.so use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_krb5.so

It is also necessary to edit smb.conf to add:
template shell = /bin/bash
otherwise AD users get no shell (/bin/false) by default.

Sorry for the long post but I hope it is helpful. looking forward to further progress.

Regards,

Stephen Jones

Hi,

Well, with a little work, I have managed to produce a working installation of opsi with Samba4 running on CentOS 6.3, so I would like to post the procedure here.

I am using Samba4 version 4.0.1 installed from RPM built by SOGo, as RedHat/CentOS have not yet released their official version. SOGo use Samba4 with their OpenChange product.

First step is to rebuild the opsi-depotserver RPM to remove the dependency on samba (ie. Samba3). Download the opsi-depotserver source RPM and install into the rpmbuild environment of a non-root user: Edit ~/rpmbuild/SPECS/opsi-depotserver.spec and delete 'samba' from 'Requires:'. I also decided to change the locations /home/opsiproducts to /var/lib/opsi/workbench and /opt/pcbin/install to /var/lib/opsi/depot to comply with best practice, so I edited those paths under the [install] and [files] sections. I also removed the code from the %pre, %post and %postun sections of the spec file as they involve adding users/groups, which I plan to do manually. Now rebuild the package from the modified spec file (again as non-root user): Install the modified opsi-depotserver package as root: The package and all its dependencies installed successfully without Samba3.

Despite removing the user/group creation from the rebuilt opsi-depotserver package, they had still been added, obviously from another opsi RPM. Therefore I remove the users/groups so as I can recreate them in a way to work with Samba4. In creating the philosophy for accounts in Unix/Windows AD it is important to realise that a unix user cannot belong to an AD group, but an AD user can belong to a unix group. The user account pcpatch must be created in AD. The group pcpatch is renamed to opsifileadmins (due to AD name restrictions) and created as a group in AD. pcpatch is a member of opsifileadmins. User opsiconfd remains a unix account to run the daemon. opsiconfd had pcpatch as its primary group, which is no longer possible, so I create a group opsiconfd for the user. This is standard with other services like mysql, apache, postfix, etc., so why not with opsi? The group opsiadmin remains a unix group controlling access to configuration. User opsiconfd is added to group opsiadmin, along with any user (unix or AD) given access to opsi-configed. Create the unix users and groups: Open the AD Users and Computers tool on a Windows client in the domain and create the user pcpatch. Unset 'user must change password at next logon', and set 'user cannot change password' and 'password never expires'. Create the group opsifileadmins and add pcpatch as a member. Open the properties for pcpatch and under 'member of' set opsifileadmins as the primary group, then remove the group Domain Users.

Edit /etc/opsi/opsi.conf and change it to read: Add any AD users who are to configure opsi to the opsiadmin group. Unix root account can also be added. For example: Make sure that /etc/nsswitch.conf has been modified to use winbind thus: It is also important that PAM has been configured to allow access via kerberos and/or winbind for AD users. I showed how to do this in a previous post in this thread. Either method is adequate, but I included both. Note also the requirement in smb.conf for: When this is successful, aduser should be able to login to the server by SSH. In the case of user pcpatch there is a problem. The Samba4 default template homedir = /home/%D/%U translating to /home/DOMAIN/pcpatch. We don't want to change this default, but we want pcpatch home to be /var/lib/opsi, so create a link Everything is now ready to proceed with the setup as per the guide - almost. Becasue I changed the package to relocate the undesirable /home/opsiproducts and /opt/pcbin/install, I edited one line of the opsi-setup script to make them /var/lib/opsi/workbench and /var/lib/opsi/depot as the code would not automatically pick up on this.

Run opsi-setup with 'configure-mysql', 'init-current-config', and 'set-rights' as per the guide. All worked OK. Do not use 'auto-configure-samba' as we setup Samba4 manually. I do not see the point in creating 3 different samba shares like the standard setup, especially since everything is under one place and fine-grain access control is available with ACLs. Create the share 'opsi' by adding to /etc/samba4/smb.conf: I changed the owner/group of /var/lib/opsi recursively to opsiconfd then, from Windows, modified the security settings of the opsi share to grant full control to Administrator and opsifileadmins (and opsiconfd). This is a reasonable starting point. More specific controls can be added, for example, to make the depot subdirectory read-only. Because I changed the depot share from the default, it is also necessary to edit the depot config file /var/lib/opsi/config/depots/server.domain.local.ini and set: Starting the opsiconfd/opsipxeconfd services did produce a couple of warnings (python messages), but the services still start successfully. I will raise the warnings in a separate post.

With opsiconfd running, I now try to connect to the server from opsi-configed on a Windows client, but it kept failing. The client log file on the server was showing PAM authentication errors, even though aduser can login by SSH, and aduser belongs to opsiadmin group. This really had me stumped for a while. Eventually, I found the problem to be in BackendManager.py in class BackendAccessControl. The code tries to identify the OS distribution and accordingly find the PAM service granting access. In the case of RHEL/CentOS it should be password-auth or system-auth (depending on version). There must be a problem with this because it obviously fails the OS test and so binds to neither. There is also a fallback called opsi-auth, which does not exist, so PAM authentication fails entirely. Rather than try to debug this (I am not a python programmer) I created a link called opsi-auth connected to my updated password-auth: This fixed it and I could now login with opsi-configed.

I ran opsi-product-manager to populate the repository, and packages were now visible in opsi-configed.
From the Windows client I installed the opsi-client-agent from the opsi file share. After reboot the client was visible in opsi-configed. I then installed software (eg. javavm) to the client successfully. I also created a package and added it to the depot. When adding the package to the depot with opsi-package-manager it produced the error:
"Error: Backend Error: Failed to install package..."
The log file shows:
Failed to set rights for path '/var/lib/opsi/config/products/mypkg.localboot': [Errno 1] Operation not permitted
Failed to set rights for path '/var/lib/opsi/config/depots/server.domain.local.ini': [Errno 1] Operation not permitted
However, the files are added to the depot and the depot config is updated. The package appears in opsi-configed and can be installed to the client, so everything works. Perhaps there is a workaround to stop the program producing these errors. Any advice would be great.

Overall opsi appears to be working properly. I hope this information is helpful to others and the developers. Any feedback is appreciated.

Regards,

Stephen Jones

Thanks for this thread! (Not that it is working for me in Debian 7, but it helps me understand some things.) Did anything happen since it was started a year ago?

And what benefit does the Debian package opsi-depotserver-expert exactly bring? It removes the dependency to Samba3 only, right? And I still have to tinker with users and permissions manually, don't I?

Is there a rough schedule for Debian / Opsi / Samba4 so that I can estimate if I'd rather tinker, wait or get rid of one part in the game?

Samba4 is currently only available as backport in wheezy. Jessie which freezes in Nov this year will ship Samba4 by default. That is the time when OPSI will depent on Samba4 on Debian.
But i cant tell when OPSI will support Jessie. The current 4.0.4 just featured support for operation on wheezy

Hello,

afaik UCS 3.2 can run Samba 4 OOB just now.
Also openSuse 13.1 and the upcoming Ubuntu releases run Samba 4.

As the opsi userbase running Debian / Ubuntu is quite large we aim to provide support for that and are yet working on it. But - as always - we will only release when it's stable enough to have a pleasant experience


With kind regards

Niko

OK, in the meantime, I decided to try and get it to work manually. It looks so close to working!

I was wondering if there is a documentation somewhere where you describe in detail how it is supposed to work. Right now I'm trying to fix permission issues in the Windows side. What does the client pc (with opsi-client-agent installed) actually do when it collects updates? Which AD user does what and how does the client-agent connect to the server (which user? which type of connection?). What does pcpatch do and what does the opsiconfd user do? If I am right, pcpatch installs the software on the client. Does it need to be in more AD groups than in "opsifileadmins"? I mean if I create that user manually in AD how does it get the permission to install stuff?

Do you have a document somewhere online where I can read that kind of information?