Custom Query (98 matches)
Results (40 - 42 of 98)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #122 | fixed | IG Utah Xen to IG GPO Xen with GRE tunnel link fails | ||
| Description |
Writing ticket to track resolution of issue in email: Running test case IG-XN-11 ( IG Utah Xen to IG GPO Xen with one GRE tunnel link) and have run into a problem. The two Xen hosts come up without a problem, but when I login to the each of hosts there is no dataplane GRE tunnel configured. Slice is IG-XN-11 and hosts are:
Waited up to 10 minutes in case the configuration portion was delayed, but no change. Also if the same RSpec is used with emulab-openvz in place of emulab-xen, GRE works. |
|||
| #21 | wontfix | iLO web interfaces for pc1 and pc3 claim to have the same SSL issuer and serial number | ||
| Description |
When i login to the web console for the pc3 iLO (at 155.98.34.104) using firefox, i get the standard firefox "do you want to trust this certificate?" dialogue, and am able to successfully connect. If i subsequently try to connect to the pc1 iLO (at 155.98.34.103) using the same firefox instance, i get the error: Secure Connection Failed
An error occurred during a connection to 155.98.34.103.
You have received an invalid certificate. Please contact the server
administrator or email correspondent and give them the following
information:
Your certificate contains the same serial number as another certificate
issued by the certificate authority. Please get a new certificate
containing a unique serial number.
(Error code: sec_error_reused_issuer_and_serial)
The page you are trying to view can not be shown because the
authenticity of the received data could not be verified.
Please contact the web site owners to inform them of this problem.
Alternatively, use the command found in the help menu to report
this broken site.
If i delete the SSL information for 155.98.34.104 from my browser and clear the cache, i can subsequently browse to .103 normally (but of course get this error again when i go back to .104). From the iLO logins, i see the following SSL information for the two devices:
So those serial numbers are indeed identical. I have verified that the other three iLOs have unique serial numbers (pc2=55, pc4=53, pc5=54), and do not experience this problem. |
|||
| #26 | fixed | incorrect MAC addresses are reported for dataplane interfaces on OpenVZ containers | ||
| Description |
I am comparing three sources of information about MAC addresses assigned to dataplane interfaces on experimental nodes:
These three data sources agree given a physical node. However, given an OpenVZ container, the second data source is incorrect, and the third is missing.
I've only tried to verify this once, using the sliver Physical Node Mapping: ID Type OS Physical --------------- ------------ --------------- ------------ phys1 dl360 FEDORA15-STD pc3 virt1 pcvm OPENVZ-STD pcvm5-1 (pc5) For this experiment, i see:
|
|||
