Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: dilligaf on May 23, 2009, 08:13:52 PM
-
server only mode
I have tried from server manager and console same results.
I have done yum clean all, clean metadata etc no go.
I have read forums, how to etc, can't find the help for my problem.
Thanks for any help in advance:
[root@smeserver db]# yum update
==============================================================
WARNING: Additional commands may be required after running yum
==============================================================
Loading "smeserver" plugin
Loading "fastestmirror" plugin
Setting up Update Process
Setting up repositories
Loading mirror speeds from cached hostfile
Reading repository metadata in from local files
Excluding Packages from CentOS - updates
Finished
Excluding Packages from CentOS - os
Finished
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for e-smith-domains to pack into transaction set.
e-smith-domains-2.0.0-1.e 100% |=========================| 24 kB 00:00
http://ftp.nluug.nl/os/Linux/distr/smeserver/releases/7/smeos/i386/SME/RPMS/e-smith-domains-2.0.0-1.el4.sme.noarch.rpm: [Errno -1] Header is not c omplete.
Trying other mirror.
e-smith-domains-2.0.0-1.e 100% |=========================| 24 kB 00:00
http://smemirror.fullnet.co.uk/releases/7/smeos/i386/SME/RPMS/e-smith-domains-2.0.0-1.el4.sme.noarch.rpm: [Errno -1] Header is not complete.
Trying other mirror.
e-smith-domains-2.0.0-1.e 100% |=========================| 24 kB 00:00
http://ftp.surfnet.nl/ftp/pub/os/Linux/distr/smeserver/releases/7/smeos/i386/SME/RPMS/e-smith-domains-2.0.0-1.el4.sme.noarch.rpm: [Errno -1] Heade r is not complete.
Trying other mirror.
e-smith-domains-2.0.0-1.e 100% |=========================| 24 kB 00:00
http://mirror.pacific.net.au/linux/smeserver/releases/7/smeos/i386/SME/RPMS/e-smith-domains-2.0.0-1.el4.sme.noarch.rpm: [Errno -1] Header is not c omplete.
Trying other mirror.
e-smith-domains-2.0.0-1.e 100% |=========================| 24 kB 00:00
http://distro.ibiblio.org/pub/linux/distributions/smeserver/releases/7/smeos/i386/SME/RPMS/e-smith-domains-2.0.0-1.el4.sme.noarch.rpm: [Errno -1] Header is not complete.
Trying other mirror.
e-smith-domains-2.0.0-1.e 100% |=========================| 24 kB 00:00
http://sme-mirror.voxteneo.com/releases/7/smeos/i386/SME/RPMS/e-smith-domains-2.0.0-1.el4.sme.noarch.rpm: [Errno -1] Header is not complete.
Trying other mirror.
Error: failure: SME/RPMS/e-smith-domains-2.0.0-1.el4.sme.noarch.rpm from smeos: [Errno 256] No more mirrors to try.
================================================================
No new rpms were installed. No additional commands are required.
================================================================
-
hi
did you read here (http://forums.contribs.org/index.php/topic,43994.0.html)?
how does your SME connect to internet?
did you canghe anything in the connection?
do you use a proxy?
ciao
Stefano
-
yes I did, the wgets succeed , the yum install local fails same as other person in that post.
sme server connects via hi_speed wireless ISP.
it is behind a fortigate firewall (same as many "working" installs)
no proxy
eth0 Link encap:Ethernet HWaddr 00:19:D1:E6:20:84
inet addr:192.168.123.11 Bcast:192.168.123.255 Mask:255.255.255.0
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:20438 errors:0 dropped:0 overruns:0 frame:0
TX packets:14861 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:19413785 (18.5 MiB) TX bytes:2436623 (2.3 MiB)
Memory:90400000-90420000
-
yes I did, the wgets succeed , the yum install local fails same as other person in that post.
sme server connects via hi_speed wireless ISP.
it is behind a fortigate firewall (same as many "working" installs)
no proxy.
ok.. just for test, can you restart the fortigate (bleah) firewall and retry?
Ciao
Stefano
-
rebooted everything same results, no go
-
rebooted everything same results, no go
ok..
read here (https://lists.dulug.duke.edu/pipermail/yum/2005-July/006996.html) and try to check if you are behind a transparent proxy
hth
Ciao
Stefano
-
I tried what was shown there, then modified, same reults below:
[root@smeserver ~]# echo -e "TRACE / HTTP/1.1\nHost: yum-server.example.com\n\n" | nc yum-server.example.com 80
yum-server.example.com: forward host lookup failed: Unknown host
[root@smeserver ~]#
[root@smeserver ~]#
[root@smeserver ~]# echo -e "TRACE / HTTP/1.1\nHost: yum-server.http://distro.ibiblio.org\n\n" | nc yum-server.http://distro.ibiblio.org 80
yum-server.http://distro.ibiblio.org: forward host lookup failed: Unknown host
-
ahem..
I think it should be something like
echo -e "TRACE / HTTP/1.1\nHost: distro.ibiblio.com\n\n" | nc distro.ibiblio.com 80
ciao
Stefano
-
this is what I get:
[root@smeserver ~]# echo -e "TRACE / HTTP/1.1\nHost: distro.ibiblio.com\n\n" | nc distro.ibiblio.com 80
distro.ibiblio.com: forward host lookup failed: Unknown host
[root@smeserver ~]#
-
dilligaf
Go here http://w3dt.net/tools/mturoute/ (http://w3dt.net/tools/mturoute/) and click the MTURoute button.
Cut and paste the results here, it may take a few minutes for the test to complete.
Server-only mode?
it is behind a fortigate firewall (same as many "working" installs)
So the difference is the ISP and connection type....correct?
-
yes server only mode:
mturoute to 72.45.88.114, 30 hops max, variable sized packets
* ICMP Fragmentation is not permitted. *
* Maximum payload is 2040 bytes. *
1 +-++-+-++--++ host: 203.221.91.1 max: 1500 bytes
2 +-++-+-++--++ host: 203.220.7.193 max: 1500 bytes
3 +-++-+-++--++ host: 203.220.112.141 max: 1500 bytes
4 +-++-+-++--+.+ host: 203.220.112.141 max: 1500 bytes
5 +-++-+-++--++ host: 202.7.162.61 max: 1500 bytes
6 +-++-+-++--++ host: 66.162.129.149 max: 1500 bytes
7 +-++-+-++--++ host: 64.129.248.19 max: 1500 bytes
8 +-++-+-++--++ host: 208.38.16.146 max: 1500 bytes
9 +-++-+-++--++ host: 208.38.15.166 max: 1500 bytes
10 ... (host 172.31.0.3 is not responding)
11 ... (host 192.168.0.17 is not responding)
12 +-++-+-++--++ host: 72.45.88.114 max: 1500 bytes
-
Well that's interesting, sure does tell you something.
Something is foobar for sure, if nothing else.
is not responding
Certainly is a major clue.
Are you Cable or DSL?
Looks like Cable, however 10 & 11 indicate possible DSL, need to confirm that.
Also 10 is not a private address space, 11 is.
If your Cable then 10 is foobar.
Looks like a foobar network on the private side.
How about a network system map.
Detail with model info of hardware, for example.....
modem # & IP >>> IP -- firewall # -- IP >>> switch >>> sme IP etc.
With a foobar network config yum will not send or receive packets at all or properly at the socket layer.
What that means is you have to fix your network.
If there are any transparent proxies, they at this point appear to be ok, since all ahead of your (modem) private network are responding properly.
The concept is, the more info the faster a solution.
Also, your much better off in Gateway Mode, however you can switch to that later, after we get Server only working.
No sense in compounding the problems at this point.
IMHO this community needs a good networking tutorial, would you not agree?
I'm working on it, just need a round tuit.
-
it's wireless hi-speed from a local ISP.
pretty basic setup, ISP wireless equip, cisco switch, fortigate router, sme server.
I think I may bring server to our office, try it here.
-
yes server only mode:
mturoute to 72.45.88.114, 30 hops max, variable sized packets
10 ... (host 172.31.0.3 is not responding)
11 ... (host 192.168.0.17 is not responding)
12 +-++-+-++--++ host: 72.45.88.114 max: 1500 bytes
I guess 72.45.88.114 is your ip.. in this case your isp has some problems with his network setup..
Ciao
Stefano
-
Caio
How did you gleam that from the test??
-
it's wireless hi-speed from a local ISP.
That's fine, works just like any other wired or wireless network.
It's not a problem with SME server.
It's not a problem with your isp.
It's not a problem with a proxy or a transparent proxy.
It's a 100% private network config issue.
The test clearly indicates that.
10 ... (host 172.31.0.3 is not responding) >>>> http://en.wikipedia.org/wiki/IP_address (http://en.wikipedia.org/wiki/IP_address)
11 ... (host 192.168.0.17 is not responding)
Lets look at it again....
1 +-++-+-++--++ host: 203.221.91.1 max: 1500 bytes EXTERNAL
2 +-++-+-++--++ host: 203.220.7.193 max: 1500 bytes EXTERNAL
3 +-++-+-++--++ host: 203.220.112.141 max: 1500 bytes EXTERNAL
4 +-++-+-++--+.+ host: 203.220.112.141 max: 1500 bytes EXTERNAL
5 +-++-+-++--++ host: 202.7.162.61 max: 1500 bytes EXTERNAL
6 +-++-+-++--++ host: 66.162.129.149 max: 1500 bytes EXTERNAL
7 +-++-+-++--++ host: 64.129.248.19 max: 1500 bytes EXTERNAL
8 +-++-+-++--++ host: 208.38.16.146 max: 1500 bytes EXTERNAL
9 +-++-+-++--++ host: 208.38.15.166 max: 1500 bytes EXTERNAL
10 ... (host 172.31.0.3 is not responding) INTERNAL
11 ... (host 192.168.0.17 is not responding) INTERNAL
12 +-++-+-++--++ host: 72.45.88.114 max: 1500 bytes EXTERNAL
10 and 11 shouldn't be there, they are private address's beyond your modem, the outside world like in WWW.
ISP wireless equip, cisco switch, fortigate router, sme server.
Why is the switch between ISP wireless equip and the fortigate, exactly what is connected to it?
Here what it should look like.
mturoute to 72.19.14.11, 30 hops max, variable sized packets
* ICMP Fragmentation is not permitted. *
* Maximum payload is 2040 bytes. *
1 +-++-+-++--++ host: 112.221.91.1 max: 1500 bytes
2 +-++-+-++--++ host: 112.220.7.193 max: 1500 bytes
3 +-++-+-++--++ host: 112.220.112.77 max: 1500 bytes
4 +-++-+-++--++ host: 112.220.112.77 max: 1500 bytes
5 +-++-+-++--++ host: 202.7.162.61 max: 1500 bytes
6 +-++-+-++--++ host: 86.162.129.149 max: 1500 bytes
7 +-++-+-++--++ host: 86.192.242.190 max: 1500 bytes
8 +-++-+-++--++ host: 86.109.6.136 max: 1500 bytes
9 +-++-+-++--++ host: 86.109.6.7 max: 1500 bytes
10 +-++-+-++--++ host: 86.109.6.5 max: 1500 bytes
11 +-++-+-++--++ host: 86.109.6.1 max: 1500 bytes
12 +-++-+-.++--++ host: 86.109.6.39 max: 1500 bytes
13 +-++-+-++--++ host: 86.109.6.37 max: 1500 bytes
14 +-++-+-++--++ host: 86.109.6.35 max: 1500 bytes
15 +-++-+-++--++ host: 86.109.6.105 max: 1500 bytes
16 +-++-+-++--++ host: 29.95.228.201 max: 1500 bytes
17 +-++-+-++--++ host: 29.95.232.67 max: 1500 bytes
18 +-++-+-++--++ host: 72.19.14.11 max: 1500 bytes
ALL EXTERNAL
If you want yum to work, fix the network.
Yum will not work unless your network is 100%, that's a fact.
The test clearly shows it's not 100%, fact.
That's why I gave you that particular test.
-
That's fine, works just like any other wired or wireless network.
It's not a problem with SME server.
It's not a problem with your isp.
It's not a problem with a proxy or a transparent proxy.
It's a 100% private network config issue.
hops 10 and 11 are of his ISP..
it's a widely used (mis)configuration of many wireless ISP
I've noticed the same behaviour with a customer of mine, here, in italy
OP can't fix anything as it's outside his router..
Ciao
Stefano
-
Took me a while to figure it out.
It's not a mis config.
I kept forgetting it's wireless on the wan side of the fence.
These are the wireless link IP's and they disabled ping response for obvious reasons, not that it matters much.
10 ... (host 172.31.0.3 is not responding) INTERNAL
11 ... (host 192.168.0.17 is not responding) INTERNAL
So the wan side is OK for all we can assume at this point.
What I would say is connect SME directly to the Wireless with nothing else, just SME and retest.
That will verify the upstream Wan with SME.
If that works, then it's a foobar network and we're back to Lan side hunting & diag.
Really need to verify SME by itself working with the Wireless ISP.
hth
-
At this point we don't know if the problem is WAN or LAN side.
Need to eliminate one or the other.
No sense trying to fix the Lan side if the Wan side doesn't work.
-
poking around at fortinet newsgroups, fortinet and some other utm appliances have these issue, is there a way to manually get all the updates?:
There were some mention several months ago about this issue with CentOS linux (not all linuxes); you can do some googling and you'll find that it's not a fortinet only episode, it happened with some other vendor.
I use fedora with yum updates, my box is behind fortigate running 4.0, with no issues. I' ve tested with and without AV for HTTP;
You can test if the issue arises with centOS yum behind a FGT using AV HTTP in the protection profile for that traffic.
Also test with this: (mirrors.kernel.org is a yum updates host)
echo -e "TRACE / HTTP/1.1\nHost: mirrors.kernel.org\n\n" | nc mirrors.kernel.org 80
I'll try with/without HTTP AV profile and if you cannot determine the cause, i'll recommend updating linux servers with apt-get (this issue seems to be only yum related)
-
Suggest you connect SME and only SME to your modem and test yum.
That will tell you if sme and www will work, if it does work, then the problem is your network setup.
I see you've had other issues, my guess, since I don't have info and not sitting at your network, you have a network issue.
Yum is finicky about the network working 100%.
Yum is deliberately programmed to test the packet stream to ensure it's ok, so it doesn't d/l corrupt files and save them.
Makes no sense updating with corrupted d/l files.
From the info you have given so far, your network is not setup properly.
Connect SME in gateway mode so you can admin from the internal interface and connect directly to the modem.
Once you report the results, then it's possible someone will look into a yum issue, if it still doesn't work.
Chances are it will.
As of now your lan has not been verified to be setup properly.
Need to isolate SME connected to the modem only.
Your mtu tested good source to destination firewall to firewall.
We know the yum servers are ok and it looks like the wan to you is ok.
That leaves your internal network and that has yet to be confirmed ok.
You have a packet framing issue, that is what yum is telling you, well maybe not you, certainly me.
Something on your network is the likely cause.
I use fedora with yum updates, my box is behind fortigate running 4.0, with no issues.
Well there ya go, at least fedora is setup properly.
That doesn't mean SME is.
Everyone on the internet that has the exact same error report as you, also has a network setup issue.
Takes 10-15 min to test SME direct to the modem, a lot less time then you've spent searching the internet.
So get er done, then we'll go from there....
We're not going to fix yum for each person who has a foobar network.
Fix your network.
There are a lot of folks that use SME and yum works for them.
Kinda says it all in a nut shell.
Beside all that, nobody is going to waste their time fixing yum if it ain't broke and
they won't try unless sme is connected directly to the modem, which rules out your network setup
as the issue during the possible bug diagnosis.
If sme still still doesn't work directly connected, make sure you have a clean install and nothing else
connected to the modem.
Leave sme connected to the modem in gateway mode so you have access
from the gateway interface.
You can connect Fedora or a Win client to SME's gateway interface.
Then file a bug in the bug tracker.
Have you read here (http://forums.contribs.org/index.php/topic,43994.0.html)?
Goto that thread, top right click Notify, then you'll get notification of new posts in that thread also.
Interesting new findings there, last posts, read them.
You can have packet framing issues on a network you think is perfectly set up.
Most everything will work, yum and VPN will not.
echo -e "TRACE / HTTP/1.1\nHost: mirrors.kernel.org\n\n" | nc mirrors.kernel.org 80
That line does nothing more the opens a connection to the designated server, much the same method that yum uses.
We already know you can hit the servers with yum, so that line should work ok for you.
If you made a connection with it, then the ability to connect to the servers is ok.
However it doesn't tell you that you don't have a network packet framing issue, that test simply can't.
HTH
-
it is behind a fortigate firewall (same as many "working" installs)
as you can read here (http://forums.contribs.org/index.php/topic,43994.0.html) it's a yum issue with fortigate fw/AV
HTH
ciao
Stefano