opsi with Samba4

[n.wenselowski]

Hello silk,

your questions should be covered in the manual.
If there are any specific questions left in the unclear feel free to ask.

With kind regards

Niko

[silk]

So. Nach einigen Tage Friemelei läuft Opsi 4.0.4 jetzt mit Samba 4.1.5. Ich würde diese Handarbeit nicht unbedingt weiterempfehlen. So viel Trial & Error, dass ich kaum wiedergeben kann, wie ich zum funktionierenden Setup kam. Die entscheidenden Infos kamen schon aus diesem Thread hier, aber dann hieß es Logs lesen und frickeln.

[lloydsystems]

Hi,

I am the creator of this thread and author of the how-to for Samba4. I have not looked at this for a long time but I am glad to see that people are using it (or at least reading it). I hope it has been helpful.

I can report that I have been running opsi under Samba4 for more than 12 months in exactly the configuration I have described and it works very well.

Opsi is an excellent system, but the tie-in to Samba3 lets it down. Samba4 has been stable for some time (I have been running it for 18 months) and is a huge step forward, providing Active Directory and the ability to use native Windows tools. If you can get your opsi system to run with Samba4 it's well worth the effort. I wanted to use opsi but I was not prepared to go back to Samba3.

I am disappointed that, 12 months after writing this post, opsi is still tied to Samba3 with no alternatives. In my opinion the best solution is to remove the dependency on Samba altogether and make the Samba setup a manual task, with options settable in an opsi config file. The current methodology is overcomplicated and inflexible. A manual setup would make it non-version specific and give the end user more control to make opsi work with their Samba system, rather than treating Samba as just an opsi utility.

They should also (I wish...) remove all the unnecessary bits of buried code that muck around with accounts and file ownership and permissions. It really shouldn't be there. I just upgraded my system from 4.0.3 to 4.0.4 and, despite removing the scripting from the RPM when rebuilding, the upgrade still did things including create a pcpatch group, overwrite my opsi.conf file and change all the file ownerships and permissions making a working installation a non-working one. WHY???

Now that I have had my whinge I will try to help with your questions...

One of the key differences with using opsi in Samba4 is the changes to the user accounts. With Samba3, Windows accounts must be linked to an underlying Linux account. This does not apply to Samba4. But all Samba does with regard to opsi is provide file shares and user accounts to access them for the client service (on the PC) to install packages and admins to build them. These are the users/groups I use with Samba4:

Linux users: opsiconfd
Linux groups: opsiconfd (members = opsiconfd), opsiadmin (members = opsiconfd + sys admins)
Windows users: pcpatch
Windows groups: opsifileadmins (members = pcpatch + sys admins)

The opsiconfd user is the system account that runs the service. The group opsiconfd I created as the primary group for that user, as standard with other Linux services. This differs from the default Samba3 setup which uses pcpatch as the group for opsiconfd, but that is not possible with Samba4 because
a) Windows does not allow a group with the same name as a user and
b) Linux users cannot belong to Windows groups.
The opsiadmin group defines users who have access to the opsi configuration. This contains opsiconfd and any user (Linux or Windows) who would run opsi-Configed. Pcpatch is the Windows account the client service uses to connect to the server. Opsifileadmins is the Windows group with access to the opsi file shares. In the default Samba3 setup this group is named pcpatch, but that must change under Samba4 because of the Windows naming restrictions. This group contains pcpatch plus any Windows user who should access the file shares to build packages, etc.

With regard to file ownership, the configuration under /etc/opsi has owner/group set to opsiconfd:opsiadmin, mode 770 for directories and 660 for files. I use only one file share, /var/lib/opsi, under which the owner/group is opsiconf:opsifileadmins. File modes are 660 and directories are 770, but the depot and workbench subdirectories are 2770. However, as I have Samba4, I can use ACLs created from Windows to define any access for other users.

I hope this is helpful. I disagree with the comment that these questions are covered in the manual. The few lines included in the documentation do not fully explain the operation and do not provide any real insight to making opsi work with Samba4.

Stephen

[ueluekmen]

Hi Stephan,

first of all, thank you for your work and your support for the opsi-project.

Opsi is an excellent system

Thank you

I can report that I have been running opsi under Samba4 for more than 12 months in exactly the configuration I have described and it works very well.

opsi works with a "complete" samba4-support on UCS-Systems (Debian based distribution from Univention http://www.univention.de) since a long time now. And we have seen many strange things in this time. It is really hard to support samba4, because they change fundamental behaviours in steps of normal updates. So we have every time seen the problems and have worked hours and days to fix this problems. That is not, what I understand under a stable system. What ever, the other distributions have no support for samba4. Now Ubuntu and openSuse will release their next versions with samba4 but with not a "complete" samba4 support, so you can use samba4 like samba3 (Sharesupport) but you have not advantages of ActiveDirectory structures or other features from samba4. If you want to use it, you must compile your own version and maintain your own packages or manual installations of samba4. We work in cases of samba4 together with our partners Univention and Sernet (http://www.sernet.de).

You can do it this way, if you like it and be able to do it. But the most of opsi-Users are not familiar with linux systems. The most people comes from the Windows-World. They are scared if they see a putty window. If I would say, hey... here are cool stuff, you have to get the sources from there, perhaps deploy some patches on it, and compile it... they will show me the door and say: thank you.

Another aspect is, you can do your stuff on your machine. But if we change anything, that will break the normal behaviours of opsi, than it must work on all supported systems and all supported versions. And then, it must be ready for update. Our customers will not use our software, if every update ends in a support-Ticket. The big advantage of opsi is, that it will work out of the box. But we pay for these feature with flexibility from other special setups.

I am disappointed that, 12 months after writing this post, opsi is still tied to Samba3 with no alternatives

That is not right. You can be disappointed, but we have since years now the opsi-depotserver-expert package. This package is the same like opsi-depotserver package, but have no dependencies to opsi-atftpd, samba, sudo, wget. And the package have no postinst actions in it. This package was build for people like you and mainly for our technical partners. If you know what you are doing you should use this package instead of opsi-depotserver package.

This package is only available for Debian-Based machines. The reason is very simple. We support RPM-Based Servers, too. But we have not enough opsi installations on RPM-Based Distributions. So we don't get enough Feedback for this type of machines. If you ask yourself, why opsi don't move in the direction like you think it should do, you should ask, why is the rpm-service and rpm-packaging in the stone-age? If you maintain some packages for RPM-Based machines, you will see really fast, why it is hard to build packages for that systems. In the most cases, the users use our Virtual Appliance for evaluating, and if they decide to use opsi, they continue to use the virtual-machine from the evaluation and then they have ubuntu.

We have a internal Ticket, that the opsi-depotserver-expert package should be available for RPM-Based machines, but this is not a payed task, so it will take some time, until the Ticket will get a higher priority. If you want spend some money, you are welcome to buy these for you and the others from the community. Or you can build these package, and send us a patch. That would be great...

They should also (I wish...) remove all the unnecessary bits of buried code that muck around with accounts and file ownership and permissions. It really shouldn't be there. I just upgraded my system from 4.0.3 to 4.0.4 and, despite removing the scripting from the RPM when rebuilding, the upgrade still did things including create a pcpatch group, overwrite my opsi.conf file and change all the file ownerships and permissions making a working installation a non-working one. WHY???

I don't know, where you have modified what. But, this tasks will not be made by opsi-depotserver, this tasks will be made by python-opsi in the postinst. If on your system, the following tasks works:

getent passwd pcpatch
getent passwd opsiconfd
getent group opsiadmin

and you have an opsi.conf, than nothing should happen. But in most cases in samba4 with full activedirectory support, you have the problem, that the base os-api have no possibility for work like these. Then the opsi-packages think, that this is a new setup and will make these actions again.

opsi is based on python. What we are working on is, to make the packages like python-opsi installable over pip. Then you have only the sources of the modules and no OS-Packaging overhead. But for python-opsi this not so easy.

I hope this is helpful. I disagree with the comment that these questions are covered in the manual. The few lines included in the documentation do not fully explain the operation and do not provide any real insight to making opsi work with Samba4.

That is right. But I don't think, that our documentation is the right place to hold these information. This is not the only topic that we actually have, for example the uefi features and the new linux-client-agent support in opsi. We discuss at the moment for an techblog for opsi. I think with a blog we have the possibility to make a detailed view on these topics. The information in our documentation about samba4 is only the essentials information, when you use UCS 3 and higher distributions. How I write at the beginning, this is the only official samba4 support in opsi since yet.

With regard to file ownership, the configuration under /etc/opsi has owner/group set to opsiconfd:opsiadmin, mode 770 for directories and 660 for files. I use only one file share, /var/lib/opsi, under which the owner/group is opsiconf:opsifileadmins. File modes are 660 and directories are 770, but the depot and workbench subdirectories are 2770. However, as I have Samba4, I can use ACLs created from Windows to define any access for other users.

The Filepermissions-Implementation in opsi is not beatiful and not good but it works.
We are planning to change these but not in the rolling release under opsi 4.0. This will maybe changed in the next major release of opsi.

Last but not least, we are working on the next release (rolling release in opsi). One of the main goal is to support Ubuntu 14.04 and openSuse 13.1. Then opsi will work better with samba3 and samba4.

[lloydsystems]

Thanks for the feedback. I was told of the UCS solution when I first asked about Samba4, but I would not consider UCS as an option for my server OS for several reasons. I was also told about the 'expert' version of opsi, which would be ideal, but unfortunately it was, and still is, only available for Debian. I hope this will change in the near future.

I personally don't much care for Debian, and particularly its derivatives - perhaps because I came from commercial Unix. RHEL was the first Linux to impress me. I use CentOS because I consider RHEL/CentOS to be the best choice for a Linux server OS due to stability, security and support life-cycle. In these key areas it outperforms everything else. It may be slower to get the latest features and versions, but that's because everything must be tested and guaranteed stable and compatible, and that's a trade-off I'll accept any day.

To say that Debian software management is any better than RPM is simply not true. If RPM is archaic then so is DEB because they are both just an archive with some metadata. The packages are built in basically the same way and installing with APT or YUM does exactly the same thing. So DEB versus RPM, APT versus YUM, control file versus spec file..... one is no better or worse than the other.

For Samba4 I used the package built by the SOGo group. They have packages available for several distributions. I could have built it myself but did not want the maintenance overhead. It may not have every little feature but the important stuff is certainly there, and I have found it to be stable.

In terms of what happened during my recent opsi version upgrade, the commands you listed

Code: Alles auswählen

getent passwd pcpatch
getent passwd opsiconfd
getent group opsiadmin

all work on my system and, of course, I do have a opsi.conf file. Yet it did screw everything up. I had removed the scripting from the opsi-depotserver package when I rebuilt it, so it must have been caused by python-opsi. If you believe that "nothing should happen" then perhaps the developers should take a look at it.

Stephen Jones

[Landskroner]

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

[n.wenselowski]

Maybe with 4.0.5 but we can not guarantee it right now.

-N