Koozali.org: home of the SME Server
Legacy Forums => General Discussion (Legacy) => Topic started by: grattman on August 29, 2005, 10:59:39 PM
-
We are currently running SME 6.0.1 at two schools I manage. The SAU was implemented a new SIS (Student Information System) by PowerSchool (www.poerschool.com - An Apple product now). The issue I have is that utilizing PowerGrade, a fat-client application on the teachers computer. It is supposed to connect to the PowerSchool server to synch attendance and grades. It seems that SME, or some component within the SME structure is blocking request from the client to the server. The client uses port 80 to communicate with the server.
I ahve tried disabling DansGuardian as a possible suspect, but that didn't work.
So....my question is, and please consider me a SME/Linux newb, what else could be running that would block access on port 80? And if you know, how do I work around it?
And for additional brownie points.....one of my SME 6.0.1 installs has some issues, and I am considering migrating to 6.5. Is there an easy way to do this?
Thanks,
grattman
-
grattman
> It seems that SME, or some component within the
> SME structure is blocking request from the client > to the server.
Not necessarily. Perhaps you need to configure the client application to access the sme proxy port (3128 or 8080 if using Dansguardian), that fixes the issue in similar sort of situations.
> I am considering migrating to 6.5.
> Is there an easy way to do this?
Insert CD, run upgrade
To be safe, uninstall any incompatible contribs first.
You may even like to try it on a test installation to be familiar with the process and discover any problems before doing it on your production server.
-
Ray,
Thanks for the quick reply. Wouldn't turning off DansGuardian have resolved it using port 8080?
[Update] I completely removed DansGuardian from the server and this had no impact on my issue.
Where can I look to see what is being logged on the SME server with regards to the outgoing request? If there is such a place, that might clue me in to the issue. Forgive my SME/Linux ineptness, I come from a Windowz world.
Also, there is no way that I know of to alter the application.
Thanks,
garttman
-
Not sure who will pick up on this, but we figured out what we think is going on.
The program uses (by default with no way of changing it) port 80 to access the remote server. It would seem that it sends out a request with out any http header information. Squid then picks up the request and inserts some type of header information. The remote server sees this is denies access. We changed the port to another port and it works fine.
I know the obvious answer is "just use another port." However, the TECH Coordinator wants to use port 80 and this is a battle I don't think I can win.
I have tried several work arounds, such as:
http://www.bmannconsulting.com/node/652
http://www.tech-geeks.org/contrib/loveless/SMEServer/contribs/squidProperties/
Neither of which made a difference. Does anyone have anything else to lend to this issue. The alternative is for me to switch to another flavor of Linux which I do not want to do.
Thanks,
grattman
-
Did you try just disabling squid?
/sbin/e-smith/config setprop squid status disabled
then post upgrade and reboot...
/sbin/e-smith/signal-event post-upgrade
reboot
-
then post upgrade and reboot
Can you expand on this a bit. I don't understand the post upgrade aspect? What does post upgrade do with regards to squid?
And if this does not work, or renders DansGuardian ineffective, does
/sbin/e-smith/config setprop squid status enabled
/sbin/e-smith/signal-event post-upgrade
Return it to normal?
-
Did you try just disabling squid?
/sbin/e-smith/config setprop squid status disabled
then post upgrade and reboot...
/sbin/e-smith/signal-event post-upgrade
reboot
As I suspected, this is not a viable option. DansGuardian relies on squid for proxying. This being an Elementary School server, DG has to be there by law. Anyone else got a suggestion?
Thanks,
grattman
-
I thought you "completely removed DansGuardian from the server".
Did you try it at least for a second to make sure that squid is the problem? Do that.
-
does
/sbin/e-smith/config setprop squid status enabled
/sbin/e-smith/signal-event post-upgrade
Return it to normal?
No, you have to type 'reboot' after that. Settings are updated after a reboot.
-
I had removed DansGuardian, but only over the weekend. It had to be in place when school is in session. Squid is definitely the issue, not DG. I have renabled both squid and DG and am awaiting any other ideas.
Thanks,
grattman
-
grattman
I don't know if this comment is really related to your problem or not.
>> Perhaps you need to configure the client
>> application to access the sme proxy port (3128 or >> 8080 if using Dansguardian), that fixes the issue >> in similar sort of situations.
> Wouldn't turning off
> DansGuardian have resolved it using port 8080?
Well it depends if you have set the transproxy port on sme server or not.
Have you ever issued this command ?
/sbin/e-smith/db configuration setprop squid TransparentPort 8080
/sbin/e-smith/signal-event post-upgrade
/sbin/e-smith/signal-event reboot
-
Even with squid and dansguardian installed I'm 99% sure nothing is set by default to block port 80. The TransparentPort setting can be 3128 (if only squid) or 8080 (with squid+dansguardian), but SME doesn't block port 80 unless you've done something else with iptables to block it. Would you agree, Ray?
-
I have determined squid/DG it is not blocking port 80. However, squid/DG is inserting http header information in to some degree on the outgoing request. And the server receiving the request does not like whatever info it has inserted.
Thanks,
grattman
-
gregswallow
> ...SME doesn't block port 80 unless you've done something else with iptables to block it. Would you agree, Ray?
Yes, but I think the dungog contrib implementation of DG does block port 80 to prevent users circumventing dansguardian filtering
grattman, what DG contrib are you using, dungog's (?), or did you implement it as per my how to.
Did you make any custom template/masq/iptables changes to port 80 ?
-
Dungog implementation Ray. I imagine I could do your version now that I understand it more. But when I removed DG, it still didn't fix the problem. Additionally, I have made no other iptable/masq changes. Not clue how to :-)
-
I don't know how accessible the clients are, or if this will help, but a quick google on "powerschool proxy" finds a few schools posting instructions on how to disable the proxy on the client in order to access the Powerschool site.
Could this be how other schools are handling a similar problem?
RonM
-
> But when I removed DG, it still didn't fix the
> problem
But did you post-upgrade and reboot, that might have been required.
If you have paid for support from Dungog, use it :-P
Probably his rpm added a template into /etc/e-smith/templates/etc/rc.d/init.d/masq/ and you'll have to edit or delete it, removing the entries similar to 'iptables ???? TCP 80 DROP' - something like that.
'rpm -qil nameofrpm' will list what files it has installed if you want to try to figure it out yourself.
-
grattman
>...removing the entries similar to 'iptables ???? TCP 80 DROP'
I believe these are the templates that get used, and yes they do DROP port 80
http://mirror.contribs.org/smeserver/contribs/rmitchell/smeserver/contribs/dansguardian/templates/masq/
-
Grattman.. did you ever get this issue resolved?
I'm battling the same issue on an SME 7 box for a local Catholic School. Their Diocese instructed all the schools to install the fat client, and now of course it doesn't work.
So, if you solved the issue, and could pass along that answer, you'd save me a lot of heartache...and head scratching.
Thanks..
P.S. All of the other schools in the Diocese are using Sonicwall Hardware firewall's with content filtering, this is the lone school in the Diocese using an SME server, I used Dungog's Dansguardian installation.
-
kansasdragon
> I'm battling the same issue on an SME 7 box
>...this is the lone school in the Diocese using an SME server,
> I used Dungog's Dansguardian installation
I don't think the problem is that hard to identify. You have installed a contrib (Dansguardian from Dungog) that stops people circumventing
Dansguardian and getting web access via port 80. You are then asking to be allowed access via port 80 to certain web sites (in effect circumventing Dansguardian).
See the templates mentioned in my post above. I assume you could remove the entries associated with port 80 (& expand templates & restart etc etc), but you then reduce the effectiveness of the contrib.
You could also set up pam auth for certain users who will then bypass dnasguardian filtering, or allow certain computers unimpeded access to the web, but the port 80 iptables rules may still be a problem.
The free version without a web panel (see my HowTo), does not use those templates, so you could temporarily try installing that (uninstall Dungog version first) & see how you go.
Otherwise become a master of iptables rules & write your own.
-
Is it possible to create a template fragement to allow outbound traffic on port 80 to a specific host? Then the students would still be constrained to use DansGuardian for general web access, but the fat client application could talk to the specified host without obstruction...
I don't understand masq enough to be of much help. I'd start by searching /etc/init.d/masq for the lines affecting port 80, guess which one is causing my headache, and put a line above it to allow traffic on port 80 to the one off-site server. If that works, "just" find the template-fragment that creates the "DROP" rule and make a new fragment with your rule that starts with a slightly lower number, expand-template, etc, etc...