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.


Messages - jgould

Pages: 1 2 [3] 4
31
News and Announcements / Re: Zentyal 4.0 Roadmap Published!
« on: August 02, 2014, 11:49:05 pm »
Rather disappointed. Radius removal makes no sense to me. They are removing features that windows servers provide which is what they are trying to replace/compete with.

I don't get the big interest in an exchange replacement. Most companies especially SMBs that I see are moving away from on premise email anyway. Easier and more reliable using hosted email and the cost actually ends of cheaper (unless you don't value your email data and don't require any redundancy, HA, fail over).

At this point Samba 4, openvpn, and CUPS are the things that Zentyal does that interest me. But honestly at this point setting samba 4 up is easy via cmd line and then handle with RSAT. OpenVPN I've been doing with cmd line for years. And CUPS has its own admin tool but I was hoping the permissions and sharing would be simplified with zentyal, however at this point the module is a mess with various bugs. So probably easier to just install Ubuntu 14.04 and set it all up without the GUI.

32
Installation and Upgrades / Re: Setting up Zentyal for Spiceworks
« on: July 31, 2014, 03:09:10 pm »
Spiceworks will pull information from Zentyal. The AD part for the "peoples" section works without issue from what I've seen.
However, scanning the Zentyal server doesn't seem to work correctly. I've been in contact with Spiceworks support on this issue. What happens on my end is that at first it works and defines it as a simple server, not a Domain Controller. But then eventually it categorizes it as a DC and then all of a sudden it can't scan it anymore. Perhaps because it treats a DC as having to be a Windows Server and ignores me when I tell it to use SSH instead.

33
Files and permissions look the same between fresh Ubuntu 14.04 and Zentyal for the various related files.

The prerotate outputs cups stop/waiting in both installations.
The postrotate outputs cups start/running, process <pid#> in ubuntu, but nothing in Zentyal.

I'm running out of ideas of what to check...

34
Definitely will post if I determine the problem. Looking at the various permissions and files I haven't come across anything.

The best workaround I can think of right now is;
1) Make a backup of cups-deamon
2) Delete everything in /logrotate/cups-deamon so logrotate shouldn't do anything to the log files now
3) Change the MaxLogSize parameter in /etc/cups/cupsd.conf to MaxLogSize 1048576 (ie. 1M).
4) Optionally, change LogLevel to none

This doesn't do "daily" log rotation. It should allow cups to manage it's own log files and rotate them at a set size. Changing LogLevel to none should just help reduce/remove the logging so it doesn't (accidentally) grown out of control or anything.

EDIT: I'm actually going to fire up a Ubuntu 14.04 VM that has working cups/logrotate and see if the problem exists there. If not then I'll start comparing things and see what I find. Maybe that will help.  :-\

EDIT2: logrotate works as expected in a Ubuntu 14.04 VM. So time to investigate and see what I find...

35
EDIT

Sorry to keep posting, but I'm debugging and want to put all my thoughts somewhere for others.
I'm looking at the prerotate and postrotate scrips in /logrotate/cups-deamon . I'm interested in the following lines.

Code: [Select]
        prerotate
                        ....
                        touch /var/run/cups/cupsd.stopped
                        ...
                fi
        endscript
        postrotate
               ...
                if [ -e /var/run/cups/cupsd.stopped ]; then
                        rm /var/run/cups/cupsd.stopped
               ...

So before rotating the logs it should create a cupsd.stopped file in /var/run/cups/. After the rotation it should check if that file exists (-e) and if it does then remove the file and start cups.

It looks like the prerotate IS working. The cupsd.stopped file IS created. It is also deleted. But process does not start.

36
Yep, definitely logrotate

Confirmed doing the following (must have data in the cups logs for it to work);

logrotate -f /etc/logrotate.conf

Output...
Code: [Select]
2014/07/29 10:03:54| WARNING: (B) '127.0.0.0/8' is a subnetwork of (A) '127.0.0.0/8'
2014/07/29 10:03:54| WARNING: because of this '127.0.0.0/8' is ignored to keep splay tree searching predictable
2014/07/29 10:03:54| WARNING: You should probably remove '127.0.0.0/8' from the ACL named 'to_localhost'
2014/07/29 10:03:54| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2014/07/29 10:03:54| WARNING: because of this '::1' is ignored to keep splay tree searching predictable
2014/07/29 10:03:54| WARNING: You should probably remove '::1' from the ACL named 'to_localhost'
2014/07/29 10:03:54| WARNING: (B) '127.0.0.0/8' is a subnetwork of (A) '127.0.0.0/8'
2014/07/29 10:03:54| WARNING: because of this '127.0.0.0/8' is ignored to keep splay tree searching predictable
2014/07/29 10:03:54| WARNING: You should probably remove '127.0.0.0/8' from the ACL named 'to_localhost'
2014/07/29 10:03:54| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2014/07/29 10:03:54| WARNING: because of this '::1' is ignored to keep splay tree searching predictable
2014/07/29 10:03:54| WARNING: You should probably remove '::1' from the ACL named 'to_localhost'
 * Restarting Zentyal module: haproxy                                    [ OK ]
 * Restarting Zentyal module: webadmin                                   [ OK ]
 * Restarting Zentyal module: logs                                       [ OK ]
 * Restarting Zentyal module: events                                     [ OK ]

And after the printer module is down. Interest that it doesn't show the printer module even being restarted, yet if you check /var/logs/cups/ it clearly rotated the logs. So it has to be stopping the module, but not restarting.

If you run it again right after this, because of the ifempty set in the logrotate configuration, it won't rotate the log and therefore doesn't stop/start and everything remains working.

PS: I don't think it is a permissions issue on the log files. I checked and the generated files seem to have the correct permissions. I even forced the creation of the files to be "0640 root adm" and it didn't help.


Here is the /etc/logrotate.d/cups-deamon file contents.
Code: [Select]
/var/log/cups/*log {
        daily
        missingok
        rotate 7
        sharedscripts
        prerotate
                if [ -e /var/run/cups/cupsd.pid ]; then
                        invoke-rc.d --quiet cups stop > /dev/null
                        touch /var/run/cups/cupsd.stopped
                fi
        endscript
        postrotate
                if [ -e /var/run/cups/cupsd.stopped ]; then
                        rm /var/run/cups/cupsd.stopped
                        invoke-rc.d --quiet cups start > /dev/null
                        sleep 10
                fi
        endscript
        compress
        notifempty
        create
}

Something wrong with running the scripts perhaps?

37
So I think thefreeaccount is probably right and the issue is logrotate stopping cups so it can rotate the logs and it not restarting correctly.

I'm just not sure how best to handle this. I don't actually care about the logs right now as long as the module stays on. So what would be the best way to stop logrotate for cups only? I don't want my logs growing uncontrollably. I figure I could disable logging in the cupsd.conf file by changing it to none so the file doesn't grow out of control, although it would be nice to still have logging and have it still clean up the logs. To stop logrotate for cups only I'm not sure how to do that. If I remove the cups-deamon file from the logrotate.d folder then won't it just fall back on the logrotate.conf settings? Do I have to disable a cron job? I saw references for apache about using copytruncate to avoid restarting but not sure if that could work. I'm just not really sure the beat way to work around this. Any help?

Thanks.

38
Not sure whether this will help, but after I upgraded Zentyal from 3.4 to 3.5, cups would stop working every day because the logrotate configuration for cups was not creating the new cups log files with the correct permissions. I "fixed" by disabling logrotate for cups.

Unfortunately, I don't recall seeing those "address already in use" errors.

Thanks. I can give that a try. How exactly did you disable logrotate?

39
The problem is, unless I sit and watch for 24 hours, I don't really know when the module stops working. But the errors in the log I posted was when the printer module had stopped and an hour before that it was started. So make of that what you will.

When the printer module is stopped, printing doesn't work.

output of netstat -patun | grep 631
Code: [Select]
tcp        0      0 0.0.0.0:631             0.0.0.0:*               LISTEN      5519/cupsd
tcp6       0      0 :::631                  :::*                    LISTEN      5519/cupsd
This is while the printer module is started and functional. I assume you'd like to see this output when it is stopped so I'll have to wait for it to mess up again and post back.


Another error in the logs;
Code: [Select]
E [25/Jul/2014:09:42:44 -0400] Unable to bind socket for address [v1.::1]:631 - Cannot assign requested address.
E [25/Jul/2014:09:43:47 -0400] SSL shutdown failed: Error in the push function.

Ran the command netstat -patun | grep 631 after the printer module had stopped itself.
Nothing is outputted.

40
The problem is, unless I sit and watch for 24 hours, I don't really know when the module stops working. But the errors in the log I posted was when the printer module had stopped and an hour before that it was started. So make of that what you will.

When the printer module is stopped, printing doesn't work.

output of netstat -patun | grep 631
Code: [Select]
tcp        0      0 0.0.0.0:631             0.0.0.0:*               LISTEN      5519/cupsd
tcp6       0      0 :::631                  :::*                    LISTEN      5519/cupsd
This is while the printer module is started and functional. I assume you'd like to see this output when it is stopped so I'll have to wait for it to mess up again and post back.


Another error in the logs;
Code: [Select]
E [25/Jul/2014:09:42:44 -0400] Unable to bind socket for address [v1.::1]:631 - Cannot assign requested address.
E [25/Jul/2014:09:43:47 -0400] SSL shutdown failed: Error in the push function.

41
I'm going to open a ticket with this information (although lately it doesn't seem like anyone is looking at them), but I wanted to post it here as well.

Running the latest 3.5 and every single day the printer module stops and needs to be manually restarted.
The /var/log/cups/errors file has this in it from today.

Code: [Select]
W [25/Jul/2014:09:09:22 -0400] CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [25/Jul/2014:09:09:22 -0400] CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [25/Jul/2014:09:09:22 -0400] CreateDevice failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [25/Jul/2014:09:09:22 -0400] CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [25/Jul/2014:09:09:22 -0400] CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [25/Jul/2014:09:09:22 -0400] CreateDevice failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [25/Jul/2014:09:09:22 -0400] CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [25/Jul/2014:09:09:22 -0400] CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [25/Jul/2014:09:09:22 -0400] CreateDevice failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
E [25/Jul/2014:09:09:22 -0400] Unable to bind socket for address [v1.::1]:631 - Cannot assign requested address.
E [25/Jul/2014:09:09:22 -0400] Unable to bind socket for address 127.0.0.1:631 - Address already in use.
E [25/Jul/2014:09:09:22 -0400] Unable to bind socket for address 192.168.0.5:631 - Address already in use.


Code: [Select]
||/ Name                                 Version                 Architecture            Description
+++-====================================-=======================-=======================-=============================================================================
ii  zentyal                              3.5                     all                     Zentyal - Core metapackage
ii  zentyal-antivirus                    3.5                     all                     Zentyal - Antivirus
ii  zentyal-ca                           3.5.1                   all                     Zentyal - Certification Authority
ii  zentyal-common                       3.5                     all                     Zentyal - Common Library
ii  zentyal-core                         3.5.2                   all                     Zentyal - Core
ii  zentyal-dns                          3.5.1                   all                     Zentyal - DNS Service
ii  zentyal-ebackup                      3.5                     all                     Zentyal - Backup
ii  zentyal-firewall                     3.5                     all                     Zentyal - Firewall
ii  zentyal-ha                           3.5.2                   all                     Zentyal - High Availability
ii  zentyal-monitor                      3.5                     all                     Zentyal - Monitor
ii  zentyal-network                      3.5.1                   all                     Zentyal - Network Configuration
ii  zentyal-ntp                          3.5                     all                     Zentyal - NTP Service
ii  zentyal-objects                      3.5                     all                     Zentyal - Network Objects
ii  zentyal-office                       3.5                     all                     Zentyal - Office Suite
ii  zentyal-openvpn                      3.5                     all                     Zentyal - VPN Service
ii  zentyal-printers                     3.5.1                   all                     Zentyal - Printer Sharing Service
ii  zentyal-remoteservices               3.5                     all                     Zentyal - Cloud Client
ii  zentyal-samba                        3.5.3                   all                     Zentyal - Users, Computers and File Sharing
ii  zentyal-services                     3.5.1                   all                     Zentyal - Network Services
ii  zentyal-software                     3.5                     all                     Zentyal - Software Management
ii  zentyal-squid                        3.5.2                   all                     Zentyal - HTTP Proxy (Cache and Filter)
ii  zentyal-trafficshaping               3.5                     all                     Zentyal - Traffic Shaping
un  zentyal-users                        <none>                  <none>                  (no description available)

42
Well, like always, once I post something I find a "workaround".

The problem seems to be what Zentyal is writing to the /etc/samba/smb.conf file.
I will start by saying, I've never used "Mason" before and Perl is one of my least favorite languages.
The Mason file located at /usr/share/zentyal/stubs/samba/smb.conf.mas is used to generate the configuration files. Within that file is an argument $print
Code: [Select]
<%args>
    $workgroup
    $netbiosName
     ...
    $print => 0
     ...
</%args>
and by default it is being set to 0 (=> means something different in Perl).
It is then evaluated in this code block;
Code: [Select]
% unless ($print) {
    load printers = no
    printcap name = /dev/null
    show add printer wizard = no
    disable spoolss = yes
% }
So the default behavior here is for $print to be 0 and for it to add the lines
    load printers = no
    printcap name = /dev/null
    show add printer wizard = no
    disable spoolss = yes

to the global samba configuration in smb.conf.

I ASSUME that some other scripts should be changing the default value so the mason file has $print => 1 instead and those lines are removed from the samba configuration.
However, that does not happen when enabling the print module or adding printers through CUPS.

The quick and dirty way to fix this is change $print in smb.conf.mas to $print => 1. If this isn't something that will be fixed/changed then you'd want to probably use the hooks as mentioned in http://blogs.zentyal.org/jacalvo/2011/01/04/how-to-customize-the-configuration-files-generated-by-zentyal/.

Once I did this the printers showed up in "view remote printers". I can add the printers without the windows error now. And I can use Point'n'Print to deploy.
However the "missing argument: User/Group" issue still exists.

43
Hello,

There seems to be issues trying to use Zentyal 3.5 as a print server. I think the issue lies within something Zentyal is doing with Samba.

I'm able to add a printer using CUPS. I added them using IPP and downloaded the ppd files from the respective manufacturers. I can print a test page with CUPS. And I can even add the printer on a Windows 7 machine using IPP (http://<servername>:631/printers/<printer_name>) and print. However deploying IPP printers through Group Policy is... difficult IMO.

So instead I was going to share the printers using Samba which would allow the Point'n'Print to deploy drivers and IMO it is easier for Windows users this way. However, it just doesn't work it seems. The printer shares show at \\<servername>. If you try to connect to them though I get a windows error 0x0000002e. And if you try to follow the Samba directions https://wiki.samba.org/index.php/Samba_as_a_print_server#Uploading_printer_drivers_for_Point.27n.27Print_driver_installation and click on "view remote printers" nothing is listed.

I've become so annoyed by this that I downloaded Ubuntu 14.04 today and installed it in a VM. Installed Samba4 and CUPS. had to make a few changes to CUPS to allow remote access. Added the printer in CUPS. And then I simply browsed to the server and it was there shared by Samba. It showed in "view remote printers". Was able to follow all the directions listed by Samba and everything worked as it should.

So I don't think this is the fault of the Samba or CUPS packages, but something zentyal is doing during configuration of them. I checked the smb.conf in my Ubuntu server vs the smb.conf/shares.conf generated by Zentyal. They were different, but it seems like it should still work. To test I changed the configuration files to look like the working ones on Ubuntu, then ran an "smbcontrol all reload-config" to load them to test. I realize this would be overwritten on reboot, but it was just to test. The changes appear to take effect but the results are the same, not working on Zentyal.

Also, once you add a printer through CUPS, if you try to add a "User" access control for a printer it doesn't work. It tells you that it is "missing argument: User/Group". Group permissions get added however and appear to be written to the shares.conf file.

Also, I don't know if this is done on purpose in Zentyal, but it doesn't show in Windows 7 "Networks". You have to explicitly type \\<servername> to get to it. Perhaps this is because it is running as a Domain Controller? I mention it because I think it has to do with Samba and not sure if it is related in any way.

FYI: I installed a fresh Zentyal server today with only the necessary configurations to get it up and running and saw the same thing as listed above.

44
The changes on github in that bug thread (https://github.com/Zentyal/zentyal/pull/1405) are in the latest build. All those changes are in my system. The issue still exists. I just checked the patch noted in the thread for ldap.pm and it is not been added. I added the changes but won't be able to check if it solved my problem until later tonight. I suspect it will but isn't the fix they want to implement.

45
I'm seeing this same behavior in 3.5. I also had it in 3.4

The printers module at this point is pretty much useless to me. It hasn't worked correctly for me since 3.4 and I don't see anyone on the zentyal side really interested in looking at it. Almost like not many people use it so why bother...

Pages: 1 2 [3] 4