From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
Description of problem:
Sometimes we get cookies errors when logging into the satellite server via web
admin interface. This error persists normally. Sometimes even after restarting
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Go to https://rhn.mediaways.net/ or http://rhn.mediaways.net/
2. Login as user
3. Reload Login Page
4. Go to 2.
Actual Results: cookie error
Expected Results: Successful login.
It occurs with different browsers. NS 4.7, Mozilla 1.0 (release), Mozilla 1.2.1
(release) under Linux.
Chip, any idea?
The problem persists. It seems to get even worse. :-/
are you certain the time on both the satellite and on the system running the
browser are both correct (including timezone, etc)? also, the time on the
make sure you access the machine via its full domain name, ie, 'foo.bar.com' and
not just 'foo'.
also, what browser are you using?
My client machine is 1 minute "faster" than the Satellite Server. Timezones are
Mozilla 1.2 / Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
The machine is accessed via its fqdn.
I suggest that we give you an account on our satellite server, so that you can
experience the effect for yourself.
Would that be a help for you?
can you ensure that the output of 'hostname' on the machine in question matches
the name you're using to access it? if the machine is foo.bar.com, and
'hostname' only prints 'foo', then you will see problems similar to what you're
The system's name (hostname is lnxc-115) has to match the name of the service
name (rhn.mediaways.net)? Why's that?
And when this is the reason. Why does it happen not every time (but very often)? :-)
The apache (service) listens to rhn.mediaways.net it runs on its own virtual
interface (as virtual host on extra IP address). Does the application not
respect the effective server name under which it is running?
using the default httpd.conf that ships with the satellite, both would need to
match. if you edited your httpd.conf to properly list VirtualHosts, however, it
shouldn't be an issue -- just as long as Apache knows that it can figure out the
FQDN of the current request. if you've not updated your httpd.conf, though, but
simply have extra interfaces, you may need to modify it to understand what
hostnames are bound to what IPs. please send your httpd.conf, the output if
"ifconfig", and the output of 'host rhn.mediaways.net'
also, cookie errors may show up if you wait a long time between loading the
login page and actually logging in; if you wait to type your username/password
for longer than cookie duration, the login handler won't see the cookie (since
it has expired already). when the problem occurs, does immediately going back
to the main page (being sure to reload it) solve the issue?
There's no long wait time between loading the start/login page and logging in.
Login follows immediately after loading the start/login page.
A single reload doesn't solve the problem. Only after serveral reloads it works
when the problem occurs.
See attachments for the requested data.
Created attachment 91511 [details]
httpd.conf - Apache Config
Created attachment 91512 [details]
Created attachment 91513 [details]
host rhn.mediaways.net output
do you get the cookie problems only through rhn.mediaways.net or also through
lnxc-115.srv.mediaways.net? do you need to access it via both, or just the
can you try removing the VirtualHost section, then change the ServerName setting
to be rhn.mediaways.net?
When accessing the satellite server via lnxc-115.srv.mediaways.net there are no
cookie errors. Only while accessing it via rhn.mediaways.net.
We've now removed all occurances of lnxc-115.srv.mediaways.net and we've forced
the apache to bind only to the one IP address of rhn.mediaways.net (which has
its own service ip).
That seems to do the trick. There are no cookie errors anymore. ;-)