Koozali.org: home of the SME Server
Obsolete Releases => SME 7.x Contribs => Topic started by: daniel on October 14, 2011, 03:36:45 PM
-
Sometime in the last week any access to the openupload webapp is being blocked on the WAN side. I get a "403 Forbidden error. You don't have access to /openupload from this server"
It works successfully on the LAN side. No updates to openupload have been applied. I'm not sure the last update cycle broke it or not. Here are the last updates applied last week.
openldap.i386 2.3.43-12.el5_7.9 updates
openldap-servers.i386 2.3.43-12.el5_7.9 updates
popt.i386 1.10.2.3-22.el5_7.2 updates
rpm.i386 4.4.2.3-22.el5_7.2 updates
rpm-build.i386 4.4.2.3-22.el5_7.2 updates
rpm-libs.i386 4.4.2.3-22.el5_7.2 updates
rpm-python.i386 4.4.2.3-22.el5_7.2 updates
Open upload config is
openupload=webapp
Authentication=ldap
DbName=openuploaddb
DbPassword={blocked for security}
DbUser=openuploaduser
MaxUpload=5
MaxUploadSize=640
RequireSSL=no
access=public
status=enabled
The httpd.conf file shows that it should be allowed to the public
# OpenUpload Configuration
Alias /openupload /usr/share/openupload/www
<Directory /usr/share/openupload/www>
AllowOverride None
# RequireSSL is disabled
AddType application/x-httpd-php .php
php_admin_value open_basedir /usr/share/openupload:/var/lib/openupload
php_admin_flag file_uploads on
php_admin_flag magic_quotes Off
php_admin_flag magic_quotes_gpc Off
php_admin_value upload_max_filesize 640M
php_admin_value post_max_size 640M
php_admin_value memory_limit 640M
php_admin_value max_execution_time 0
php_admin_value upload_tmp_dir /var/lib/openupload/tmp
php_admin_value session.save_path /var/lib/openupload/tmp
order deny,allow
deny from all
allow from 127.0.0.1 192.168.93.0/255.255.255.0 204.118.121.100/255.255.255.248
Satisfy all
<FilesMatch "config.inc.php">
Order allow,deny
Deny from all
</FilesMatch>
</Directory>
I tried changing RequireSSL and changing access=public to access=private and back thinking it might rewrite the files correctly but that didn't help. Any suggestions on what I can look at next? I have not updated to the latest openupload as it requires e-smith-base in the smeupdates-testing.
-
Have you expanded apache templates after setting access to "public" ?
db configuration setprop openupload access public
expand-template /etc/httpd/conf/httpd.conf
sv t /service/httpd-e-smith
Regards, Daniel
-
Yes I have by way of a reconfigure and reboot of the server each time I made a change to try to fix it.
signal-event post-upgrade
signal-event reboot
Thanks for the suggestion. Does the httpd.conf segment I referenced not control the public access to /openupload/? I thought that was the section that allowed or denied local or public access to webpages.
-
In your configuration, the line allow from means that the access=public is not interpreted (access=public should result in allow all). Try to manually expand your httpd.conf file, there may be an error in one template preventing apache configuration to be correctly expanded.
-
Thank you, I did follow your suggestion earlier and expand the template and restart. That made no change. To further check, other shared folders and ibays also listed in the httpd.conf do permit proper access. I'm baffled by what is transpiring.
-
is there any custom template?
-
There are none for the httpd.conf file. This server is as close to SME8b6 factory as possible, with only shared folders and login script installed on it.
I do see the 98OpenUPload template fragment in the standard template folder, it is dated 2/17/11. If that had changed with the last update I would have expected the date to change on that file.
installed fws packages
smeserver-webapps-common.noarch 0.1-9.el5.fws
smeserver-openupload.noarch 0.1-7.el5.fws
openupload.noarch 0.4.2-9.el5.fws
-
There are none for the httpd.conf file. This server is as close to SME8b6 factory as possible, with only shared folders and login script installed on it.
Are you sure? What is the output of the following commands:
/sbin/e-smith/audittools/templates | grep httpd
rpm -qV smeserver-openupload
-
The results of /sbin/e-smith/audittools/templates are
/etc/e-smith/templates-custom/etc/smb.conf/11printerAdmin: MANUALLY_ADDED, ADDITION
/etc/e-smith/templates-custom/etc/smb.conf/11adminUsers: MANUALLY_ADDED, ADDITION
/etc/e-smith/templates-custom/etc/services/99bkupexec: MANUALLY_ADDED, ADDITION
/etc/e-smith/templates/etc/smb.conf/11followsymlinks: MANUALLY_ADDED
None of these affect anything httpd.conf
The rpm command did not return anything.
-
Finally figured out what was blocking the WAN side openupload app. I knew it was something in the httpd.conf. I created a new SME8b6 with the latest openupload on. Compared the two. The broken openupload had this in the httpd.conf file
deny from all
allow from 127.0.0.1 192.168.93.0/255.255.255.0 204.118.121.100/255.255.255.248
The new install shows this
deny from all
allow from all
I changed the broken one, and then did a service httpd-e-smith restart
That fixed it. Now I have to remember to do that everytime I do a signal-event post-upgrade. I checked back through the httpd.conf and any ibay or share that has public access shows allow from all instead of showing the IP addresses of each ethernet card. Thanks for everyones help.
-
Now I have to remember to do that everytime I do a signal-event post-upgrade.
No you need to find out where it is coming from, it either is a misconfiguration on your side or a bug. Since it seems to return every time my guess it is in the template system, either in a change you made manually or in the ones supplied by the package installed by you.
There are a lot more events that regenerate the webserver condiguration file then the post-upgrade event.
-
I did do more digging into httpd.conf and I found the problem. I have no idea why its happening so I'll need more expert guidance on templating.
Under server-manager | remote access I set a restricted set of remote IP 204.118.121.100/255.255.255.248 so I could remote administer from any of my public 5 IP addresses. Have had that set for over 12 months. I deleted the remote access for server-manager so it would only have local access. That instantly deleted public access to openupload as well. In the httpd.conf file it changed the allow from line for openupload to the same allow from line for whatever controls server-manager, server-common, user-password sections of the httpd.conf.
I tested the same theory on my virtual setup with SME8B6 and openupload. No matter what I set as remote access IP, it does not change the allow from line in the openupload section of the httpd.conf.
Looking at the template for httpd.conf for openupload (/etc/e-smith/templates/etc/httpd/conf/httpd.conf/98OpenUpload) I see my $allow = ($access eq 'public')?"$localAccess $externalSSLAccess":'all";
This is the same on both live server and virtual server, so I'm certain the 98OpenUpload template is not the problem. I do not know how SME determines how to write the line 'allow from $allow' in the 98OpenUpload template as
allow from 127.0.0.1 192.168.93.0/255.255.255.0 204.118.121.100/255.255.255.248
in the live server and writes the 'allow from $allow' as
allow from all
in the test file.
So far I haven't figured out where the variables $localAccess and $externalSSLAccess are located. Would someone point me in the right direction? Thanks. Any other advice?
-
I think this is a bug of openupload: access restrictions for server-manager should not have any influence on openupload..
-
It could be, but I could not duplicate the issue in another build of the same configurations, so I wasn't ready to classify it as bug yet.
-
my $allow = ($access eq 'public')?"$localAccess $externalSSLAccess":'all";
That looks wrong to me. I believe that should be:
my $allow = ($access eq 'public')? "all" : "$localAccess $externalSSLAccess";
-
Arf, you're right Charlie, the private/public handling here is reversed. It'll be fixed in smeserver-openupload-0.1-11