Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
16
Installation and Upgrades / Re: Corosync still running?
« on: May 31, 2017, 08:18:36 pm »
I will also add that pacemaker is also still running. It seems like when the Zentyal components are removed the daemons continue to run. I suspect the configurations are even still intact.
Why wouldn't Zentyal clean this up?
Why wouldn't Zentyal clean this up?
17
Installation and Upgrades / Corosync still running?
« on: May 30, 2017, 07:00:44 pm »
Hello,
My server has gone through multiple upgrades of Zentyal over the years. The HA component was dropped in Zentyal 4.1. However, my fully updated 5.0 box shows /use/sbin/corosync running and I'm not sure why. Is this being used for something else besides the old HA component? Shouldn't this have been cleaned up and removed during a previous upgrade?
Thanks.
My server has gone through multiple upgrades of Zentyal over the years. The HA component was dropped in Zentyal 4.1. However, my fully updated 5.0 box shows /use/sbin/corosync running and I'm not sure why. Is this being used for something else besides the old HA component? Shouldn't this have been cleaned up and removed during a previous upgrade?
Thanks.
18
Installation and Upgrades / Update to address Samba security vulnerability?
« on: May 30, 2017, 06:35:00 pm »
Hello,
Just wondering, since I haven't seen any announcement, thread, or bug report, did Zentyal release an update to address the Samba vunerability that was discovered a week or so ago? I'm currently running Samba v4.5.8 and my components are updated.
https://lists.samba.org/archive/samba-announce/2017/000405.html
https://www.samba.org/samba/history/samba-4.5.9.html
Samba announce mailing list recommend upgrading to 4.5.9 immediately.
I assume the only correct way to upgrade the Samba version is through the Zentyal components, right? If so I think an update is really needed ASAP.
Thank You.
Just wondering, since I haven't seen any announcement, thread, or bug report, did Zentyal release an update to address the Samba vunerability that was discovered a week or so ago? I'm currently running Samba v4.5.8 and my components are updated.
https://lists.samba.org/archive/samba-announce/2017/000405.html
https://www.samba.org/samba/history/samba-4.5.9.html
Samba announce mailing list recommend upgrading to 4.5.9 immediately.
I assume the only correct way to upgrade the Samba version is through the Zentyal components, right? If so I think an update is really needed ASAP.
Thank You.
19
News and Announcements / Re: Zentyal 5.0 available!
« on: April 10, 2017, 06:32:36 am »Hello,
CUPS or printer sharing is missing in 5.0, is there any change that it will be adapted later on ?
Best regards,
Ian
Would also like to know this.
Was just considering updating my zentyal server from 4.0 to 5.0 and then saw that CUPS was removed, which is a MAJOR part of what we use our server for (AD/DNS/Printer). It has worked well since I debugged some issues with the yaml configuration files years ago and would really like to see it included again.
20
Installation and Upgrades / Re: Question About Reverse DNS
« on: March 24, 2015, 09:58:59 pm »
I have had the same issue for well over a year. I'm not sure or versed enough to solve it though.
My understanding is that Zentyal uses Bind for DNS instead of the built in Samba DNS. If they just used the Samba DNS it supposedly handles it out of the box. Bind requires some other considerations from what I understand, but I don't really know much about Bind.
I don't use Zentyal's DHCP module, I have that running elsewhere.
It would be EXTREMELY helpful if someone at Zentyal would help with this.
This post sounds like it might be the problem.
https://forum.zentyal.org/index.php?topic=22749.0
The only way I can make reverse DNS work correctly (so all my other software stops bitching at me) is to create the reverse lookup zone using RSAT and manually define the PTR entries. Obviously this doesn't work when you are using DHCP!
As you can see, the one IP that is through DHCP (192.168.0.19) can't return a PTR. The one I've added manually does.
My understanding is that Zentyal uses Bind for DNS instead of the built in Samba DNS. If they just used the Samba DNS it supposedly handles it out of the box. Bind requires some other considerations from what I understand, but I don't really know much about Bind.
I don't use Zentyal's DHCP module, I have that running elsewhere.
It would be EXTREMELY helpful if someone at Zentyal would help with this.
This post sounds like it might be the problem.
https://forum.zentyal.org/index.php?topic=22749.0
The only way I can make reverse DNS work correctly (so all my other software stops bitching at me) is to create the reverse lookup zone using RSAT and manually define the PTR entries. Obviously this doesn't work when you are using DHCP!
As you can see, the one IP that is through DHCP (192.168.0.19) can't return a PTR. The one I've added manually does.
Code: [Select]
jgould@vdc01:~$ nslookup 192.168.0.19
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find 19.0.168.192.in-addr.arpa: NXDOMAIN
jgould@vdc01:~$ nslookup 192.168.0.72
Server: 127.0.0.1
Address: 127.0.0.1#53
72.0.168.192.in-addr.arpa name = HELPDESK.internal.domain.com.
21
Installation and Upgrades / Re: (3.5) Jabber Shared Roster
« on: January 27, 2015, 05:54:33 pm »
The posts I made were for 4.0. I've had a functional ejabberd server since posting following the info I posted above.
Is there an official way to request for Zentyal to upgrade ejabberd to a more recent version? Because this is starting to cause me some issues. For instance the old versions don't seem to support some of the new XEP. A big one for me is carbon copy.
Is there an official way to request for Zentyal to upgrade ejabberd to a more recent version? Because this is starting to cause me some issues. For instance the old versions don't seem to support some of the new XEP. A big one for me is carbon copy.
22
Installation and Upgrades / Re: (3.5) Jabber Shared Roster
« on: December 10, 2014, 11:07:45 pm »
ALSO, if anyone is out there listening, it would be GREAT to get a more recent ejabberd version. Pretty sure 2.X is obsolete. Current stable is 14.07 (https://www.ejabberd.im/).
From what I've read 2.X doesn't come with SASL GSSAPI out of the box. You have to patch it (don't think Zentyal version is patched but anyone have confirmation?) as noted at, https://www.ejabberd.im/cyrsasl_gssapi. Pretty sure the current releases come with this by default.
Considering Zentyal is using Samba 4 as an AD replacement it would make sense to use as many tools as you can to provide SSO capabilities. Openfire has had this capability for a long time and as stated ejabberd should as well. Zentyal just needs to use a current stable release.
From what I've read 2.X doesn't come with SASL GSSAPI out of the box. You have to patch it (don't think Zentyal version is patched but anyone have confirmation?) as noted at, https://www.ejabberd.im/cyrsasl_gssapi. Pretty sure the current releases come with this by default.
Considering Zentyal is using Samba 4 as an AD replacement it would make sense to use as many tools as you can to provide SSO capabilities. Openfire has had this capability for a long time and as stated ejabberd should as well. Zentyal just needs to use a current stable release.
23
Installation and Upgrades / Re: (3.5) Jabber Shared Roster
« on: December 08, 2014, 07:44:16 pm »
Should also add that the mod_vcard_ldap mapping is also incorrect.
In the config file there are references to TEL/WORK & TEL/CELL. Ejabberd is supposed to support XEP-0054 but currently it doesn't seem to fully support it. It appears these phone number references don't work. To get the "telephoneNumber" from AD just use TEL instead for now. There is a improvement/bug listed for ejabberd which I believe explains why you can't get the multiple phone numbers out of AD currently.
https://support.process-one.net/browse/EJAB-1557
Sounds like once they do implement it it will be CELL not TEL/CELL.
Zentyal group might want to fix this until the fixes are implemented. If not no telephone numbers populate.
In the config file there are references to TEL/WORK & TEL/CELL. Ejabberd is supposed to support XEP-0054 but currently it doesn't seem to fully support it. It appears these phone number references don't work. To get the "telephoneNumber" from AD just use TEL instead for now. There is a improvement/bug listed for ejabberd which I believe explains why you can't get the multiple phone numbers out of AD currently.
https://support.process-one.net/browse/EJAB-1557
Sounds like once they do implement it it will be CELL not TEL/CELL.
Zentyal group might want to fix this until the fixes are implemented. If not no telephone numbers populate.
24
Installation and Upgrades / Re: (3.5) Jabber Shared Roster
« on: December 08, 2014, 04:21:26 pm »
This is what I found over the weekend.
My Zentyal 3.5 install was using ejabberd 2.1.13. Zentyal 4.0+ seems to be using 2.1.10. Seems pretty strange that they would go "backwards" unless something was wrong. My guess is their is an issue with 2.1.13 and Zentyal.
Outside of that everything looked right on my 3.5 install and it should have worked. I tried to uninstall Jabber and reinstall but that didn't solve the issue. So after making sure nothing else I rely on would break moving to 4.0 I upgraded. During that process jabber was removed and reinstalled, now as ejabberd 2.1.10. Shared rosters now worked. The configuration file also changed when upgrading, but that wasn't the reason it worked since I had already changed the mason file (created a custom mason file like I've done in the past). The new file only changed some filters to ignore system groups.
For those unaware, the way that Zentyal configures ejabberd to identifies groups and users to add to the shared roster is by adding custom attributes or values to the attributes in your Active Directory objects. So if you are using Windows RSAT go to "Active Directory Users and Computers", click the View menu and check Advanced Features. Now double click a user account and go to Attribute Editor. I like to click the filter button and say "show only attributes that have values".
Start by looking at a user account. Look for Attribute "objectClass". There should be a value of "userJabberAccount". For user accounts there should also be custom attributes "jabberAdmin" and "jabberUid". The admin option is TRUE/FALSE to provide user accounts with admin capabilities. The Uid option is to make sure that jabber has a correctly formatted name to use for the user account. Pretty sure they do this to prevent any issue with the regular uid attribute since jabber can't have spaces and things in the username.
For groups the zentyal ejabberd configuration looks for two attributes. The first is that ObjectClass has "group" as a value. Second is that you have a "member" attribute that should contain all user accounts that belong to that group.
Another thing of importance. The Zentyal web admin won't allow you to set jabber options if the user account is in anything but the default Users folder. There is a possibility that if you add a user through RSAT or not to the default Users folder that they won't have the correct attributes for jabber. You could add/edit them in or just move the user back to the default Users folder, go into the web admin and make sure the jabber option is on. Then move the user back to wherever you wanted. This is something that anyone who really uses Active Directory and Group Policies will run into. Interestingly enough though, it doesn't seem to matter to ejabberd where user accounts are located, it picks them up fine if those attributes are there (or you change the config to look for different attributes). Personally though I don't understand why Zentyal can't allow jabber settings in the web admin outside the default User folder. Honestly, the web admin for managing Active Directory is pretty much useless as it stands. It also doesn't show computers outside the default OU.
My Zentyal 3.5 install was using ejabberd 2.1.13. Zentyal 4.0+ seems to be using 2.1.10. Seems pretty strange that they would go "backwards" unless something was wrong. My guess is their is an issue with 2.1.13 and Zentyal.
Outside of that everything looked right on my 3.5 install and it should have worked. I tried to uninstall Jabber and reinstall but that didn't solve the issue. So after making sure nothing else I rely on would break moving to 4.0 I upgraded. During that process jabber was removed and reinstalled, now as ejabberd 2.1.10. Shared rosters now worked. The configuration file also changed when upgrading, but that wasn't the reason it worked since I had already changed the mason file (created a custom mason file like I've done in the past). The new file only changed some filters to ignore system groups.
For those unaware, the way that Zentyal configures ejabberd to identifies groups and users to add to the shared roster is by adding custom attributes or values to the attributes in your Active Directory objects. So if you are using Windows RSAT go to "Active Directory Users and Computers", click the View menu and check Advanced Features. Now double click a user account and go to Attribute Editor. I like to click the filter button and say "show only attributes that have values".
Start by looking at a user account. Look for Attribute "objectClass". There should be a value of "userJabberAccount". For user accounts there should also be custom attributes "jabberAdmin" and "jabberUid". The admin option is TRUE/FALSE to provide user accounts with admin capabilities. The Uid option is to make sure that jabber has a correctly formatted name to use for the user account. Pretty sure they do this to prevent any issue with the regular uid attribute since jabber can't have spaces and things in the username.
For groups the zentyal ejabberd configuration looks for two attributes. The first is that ObjectClass has "group" as a value. Second is that you have a "member" attribute that should contain all user accounts that belong to that group.
Another thing of importance. The Zentyal web admin won't allow you to set jabber options if the user account is in anything but the default Users folder. There is a possibility that if you add a user through RSAT or not to the default Users folder that they won't have the correct attributes for jabber. You could add/edit them in or just move the user back to the default Users folder, go into the web admin and make sure the jabber option is on. Then move the user back to wherever you wanted. This is something that anyone who really uses Active Directory and Group Policies will run into. Interestingly enough though, it doesn't seem to matter to ejabberd where user accounts are located, it picks them up fine if those attributes are there (or you change the config to look for different attributes). Personally though I don't understand why Zentyal can't allow jabber settings in the web admin outside the default User folder. Honestly, the web admin for managing Active Directory is pretty much useless as it stands. It also doesn't show computers outside the default OU.
25
Installation and Upgrades / Re: (3.5) Jabber Shared Roster
« on: December 05, 2014, 11:36:28 pm »
I think I know why this doesn't work, and it isn't really related to Zentyal.
However they should probably just remove the option if it won't do anything.
According to ejabberd https://www.ejabberd.im/shared-roster-all
Checking the /etc/ejabberd/ejabberd.cfg file it shows {auth_method, ldap}. So LDAP not internal, thus no shared roster support.
EDIT:
Correction, it appears mod_shared_roster_ldap was added in 2.1.6 so this SHOULD work. No idea why it doesn't but will be looking into this as well.
However they should probably just remove the option if it won't do anything.
According to ejabberd https://www.ejabberd.im/shared-roster-all
Quote
As of version 1.0.0, ejabberd allows the administrator to add all users on a virtual host to a shared roster group. When he creates a shared roster group on a virtual host, and specifies the members, he can put @all@, and ejabberd will add all users on the current virtual host.
This feature requires internal authentication. If you use external authentication, LDAP... then adding @all@ to a shared roster group will do nothing.do nothing.
Checking the /etc/ejabberd/ejabberd.cfg file it shows {auth_method, ldap}. So LDAP not internal, thus no shared roster support.
EDIT:
Correction, it appears mod_shared_roster_ldap was added in 2.1.6 so this SHOULD work. No idea why it doesn't but will be looking into this as well.
26
Installation and Upgrades / allow printer access without authentication
« on: October 27, 2014, 09:59:53 pm »
Just wondering if anyone else can get this to work. I have some users that aren't connected to my domain. I was hoping I could allow them to connect to printers by adding it through the printer server (\\<printserver>\<sambaprintershare>) but they get asked for a login when trying to navigate to the print server. I've been unable to resolve this so far. Have tried changing samba configurations through stub files. Added
So is there a way to allow someone to add printers shared via samba without using a login?
Code: [Select]
load printers = yes and Code: [Select]
guest ok = on but still prompts for password. The "guest access" check box in the web interface doesn't seem to do anything (doesn't even change anything in the config files). Does it perhaps have to do with the type of security as mentioned HERE (ie. shared-level security vs domain-level security)So is there a way to allow someone to add printers shared via samba without using a login?
27
Installation and Upgrades / Re: Zentyal 3.5 thunderbird gassapi/kerberos configuration
« on: October 23, 2014, 05:54:02 am »
https://forum.zentyal.org/index.php?topic=23323.0
By default you want to use normal password.
I think you can make it work the other way but have to make some configuration changes. I don't know for sure what they are (hope someone does). I think it has something to do with LDAP over SSL/TLS, otherwise known as LDAPS. For instance look at THIS. And from Samba HERE.
By default you want to use normal password.
I think you can make it work the other way but have to make some configuration changes. I don't know for sure what they are (hope someone does). I think it has something to do with LDAP over SSL/TLS, otherwise known as LDAPS. For instance look at THIS. And from Samba HERE.
28
Installation and Upgrades / Re: Home Folder changing on samba restart or smbcontrol all reload-config
« on: October 23, 2014, 05:30:00 am »
So I think I figured this out, in case anyone else has the problem.
I JUST needed to alter the Users "Home Directory", which you can set using Windows RSAT. And I needed it to stick regardless of a reboot of the server or even a simple restart of samba (like when adding a printer ACL). The solution ended up being pretty easy but not all that well documented.
setting "unmanaged_home_directory = yes" basically tells zentyal/samba to not set the home directories, so you have to set them using the Windows RSAT "Active Directory Users and Computers" (which I prefer).
Interesting enough I did not experience this behavior with a pure Samba 4 installation. I THINK that Zentyal has some scripts running that are attempting to set the home directory with predefined variables that point to the local server.
I JUST needed to alter the Users "Home Directory", which you can set using Windows RSAT. And I needed it to stick regardless of a reboot of the server or even a simple restart of samba (like when adding a printer ACL). The solution ended up being pretty easy but not all that well documented.
Code: [Select]
sudo vi /etc/zentyal/samba.conf
#uncomment the last line
unmanaged_home_directory = yes
setting "unmanaged_home_directory = yes" basically tells zentyal/samba to not set the home directories, so you have to set them using the Windows RSAT "Active Directory Users and Computers" (which I prefer).
Interesting enough I did not experience this behavior with a pure Samba 4 installation. I THINK that Zentyal has some scripts running that are attempting to set the home directory with predefined variables that point to the local server.
29
Installation and Upgrades / Home Folder changing on samba restart or smbcontrol all reload-config
« on: October 15, 2014, 06:02:24 pm »
Hello,
Whenever I reboot the server, restart samba, or reload the config (smbcontrol all reload-config) the "Home" folders I have set for users using RSAT (Active Directory Users and Computers) gets changed. I set these folders to point to a NAS device. When the reload occurs the path changes to the home directory on the Zentyal Server.
I would like to stop this from happening (and be persistent) so I don't have to keep going back in and updating it. Anyone have any input?
I will also mention that all users have been created with "user quota (MB)" Disabled. There are folders for each user account in the /Home directory but that might have happened when I enabled PAM before.
Thank You.
Whenever I reboot the server, restart samba, or reload the config (smbcontrol all reload-config) the "Home" folders I have set for users using RSAT (Active Directory Users and Computers) gets changed. I set these folders to point to a NAS device. When the reload occurs the path changes to the home directory on the Zentyal Server.
I would like to stop this from happening (and be persistent) so I don't have to keep going back in and updating it. Anyone have any input?
I will also mention that all users have been created with "user quota (MB)" Disabled. There are folders for each user account in the /Home directory but that might have happened when I enabled PAM before.
Thank You.
30
Installation and Upgrades / Re: Printer sharing service always has to be restarted (Zentyal 3.4)
« on: August 16, 2014, 03:23:48 am »
I can confirm, it works for me as well. Very strange because "invoke-rc.d --quiet cups stop > /dev/null" is the default in Ubuntu and works without issue. Not so with Zentyal though.
Thanks.
I've got a whole sheet of things I have to do to a Zentyal server after upgrading modules or restarting the server. Not good...
Thanks.
I've got a whole sheet of things I have to do to a Zentyal server after upgrading modules or restarting the server. Not good...