Discussion:
Eisner offline for a few days
(too old to reply)
Simon Clubley
2020-08-27 12:05:41 UTC
Permalink
Eisner is on the move again.

VSI are moving most of their systems to a co-location facility and
Eisner will not be available for the next few days after it is shutdown
some time on Thursday.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Hunter Goatley
2020-08-31 00:12:41 UTC
Permalink
Post by Simon Clubley
Eisner is on the move again.
VSI are moving most of their systems to a co-location facility and
Eisner will not be available for the next few days after it is shutdown
some time on Thursday.
EISNER is back online! The IP address has changed, but the change to
eisner.decus.org seems to have propagated now, so you shouldn't have any
trouble logging in.

All seems to be OK, but let me know if you see anything unusual.

Thanks to Rob for getting EISNER relocated and back up!
--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
***@goatley.com http://hunter.goatley.com/
Simon Clubley
2020-08-31 00:23:08 UTC
Permalink
Post by Hunter Goatley
Post by Simon Clubley
Eisner is on the move again.
VSI are moving most of their systems to a co-location facility and
Eisner will not be available for the next few days after it is shutdown
some time on Thursday.
EISNER is back online! The IP address has changed, but the change to
eisner.decus.org seems to have propagated now, so you shouldn't have any
trouble logging in.
All seems to be OK, but let me know if you see anything unusual.
Thanks to Rob for getting EISNER relocated and back up!
Confirmed that I can connect and do various things just fine so far.

It would be interesting to know why VSI relocated most of their
systems to a co-location facility. I wonder how that affects OS level
development and doing, for example, cluster testing and development
with various cluster interconnects (unless those systems are still local
to VSI).

OTOH, having nodes in a co-location facility gives VSI more options for
forming clusters with nodes both at remote locations and local to VSI.

Just curious why they moved the systems.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Tym Stegner
2020-08-31 15:44:01 UTC
Permalink
one reason; two words: regulated power. The Bolton office is a 25+ year-old building.
Post by Simon Clubley
Post by Hunter Goatley
Post by Simon Clubley
Eisner is on the move again.
VSI are moving most of their systems to a co-location facility and
Eisner will not be available for the next few days after it is shutdown
some time on Thursday.
EISNER is back online! The IP address has changed, but the change to
eisner.decus.org seems to have propagated now, so you shouldn't have any
trouble logging in.
All seems to be OK, but let me know if you see anything unusual.
Thanks to Rob for getting EISNER relocated and back up!
Confirmed that I can connect and do various things just fine so far.
It would be interesting to know why VSI relocated most of their
systems to a co-location facility. I wonder how that affects OS level
development and doing, for example, cluster testing and development
with various cluster interconnects (unless those systems are still local
to VSI).
OTOH, having nodes in a co-location facility gives VSI more options for
forming clusters with nodes both at remote locations and local to VSI.
Just curious why they moved the systems.
Simon.
--
Simon Clubley,
Walking destinations on a map are further away than they appear.
Tym Stegner
2020-08-31 15:49:43 UTC
Permalink
I meant: one of the reasons.

due to the current medical situation, VSI is all working from home anyway, so few interconnect issues have surfaced. most clustering is down within a rack, with exceptions for clustering systems across adjacent racks. distributed clustering has been available since the introduction of Cluster-over-IP, in 8.3, I think.

-tj
Post by Tym Stegner
one reason; two words: regulated power. The Bolton office is a 25+ year-old building.
Post by Simon Clubley
Post by Hunter Goatley
Post by Simon Clubley
Eisner is on the move again.
VSI are moving most of their systems to a co-location facility and
Eisner will not be available for the next few days after it is shutdown
some time on Thursday.
EISNER is back online! The IP address has changed, but the change to
eisner.decus.org seems to have propagated now, so you shouldn't have any
trouble logging in.
All seems to be OK, but let me know if you see anything unusual.
Thanks to Rob for getting EISNER relocated and back up!
Confirmed that I can connect and do various things just fine so far.
It would be interesting to know why VSI relocated most of their
systems to a co-location facility. I wonder how that affects OS level
development and doing, for example, cluster testing and development
with various cluster interconnects (unless those systems are still local
to VSI).
OTOH, having nodes in a co-location facility gives VSI more options for
forming clusters with nodes both at remote locations and local to VSI.
Just curious why they moved the systems.
Simon.
--
Simon Clubley,
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2020-09-01 14:55:00 UTC
Permalink
Post by Tym Stegner
I meant: one of the reasons.
due to the current medical situation, VSI is all working from home
anyway, so few interconnect issues have surfaced. most clustering is
down within a rack, with exceptions for clustering systems across
adjacent racks. distributed clustering has been available since the
introduction of Cluster-over-IP, in 8.3, I think.
Apparently exposing some latent "interconnect issues" in the remote
management of OpenVMS and of OpenVMS servers, too.
Itanium is usually not difficult to run remotely, once a VPN server is
in place, Alpha requires some added giblets.
Racks and switches can be a bit more effort to configure for remote
management, though those usually restart themselves.
For newer servers, HPE ProLiant has newer iLO implementations, and Dell
has DRAC.
--
Pure Personal Opinion | HoffmanLabs LLC
John Reagan
2020-08-31 18:19:32 UTC
Permalink
one reason; two words: regulated power. The Bolton office is a 25+ year-old building.
2nd reason, air conditioning. The lab AC units in Bolton have been trouble since the beginning.

3rd reason, plumbing. The building had a continuous set of issues.

The new location has redundant power (input from two sides of the building from different power feeds), etc. The power in Bolton is just what is on the pole running down the street.
Simon Clubley
2020-09-01 18:31:01 UTC
Permalink
Post by Tym Stegner
one reason; two words: regulated power. The Bolton office is a 25+ year-old building.
$ set response/mode=good_natured

25 years ???

In Europe, it's not unusual to work in anything from a modern office
building to a 50-100 year old building and even to a 100-200 year old building.

I've never worked in a castle yet however. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2020-08-31 00:46:42 UTC
Permalink
Post by Hunter Goatley
EISNER is back online! The IP address has changed, but the change to
eisner.decus.org seems to have propagated now, so you shouldn't have any
trouble logging in.
All seems to be OK, but let me know if you see anything unusual.
I have noticed that everyone gets the same VMS-visible IP address now
in SHOW USER.

I have let Rob know in case he wasn't aware of that.

Do you have any scripts or programs running on Eisner itself which block
connections based on source IP address as seen by VMS or which do spam
scoring based on the client's IP address ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Robert A. Brooks
2020-08-31 03:47:36 UTC
Permalink
Post by Simon Clubley
Post by Hunter Goatley
EISNER is back online! The IP address has changed, but the change to
eisner.decus.org seems to have propagated now, so you shouldn't have any
trouble logging in.
All seems to be OK, but let me know if you see anything unusual.
I have noticed that everyone gets the same VMS-visible IP address now
in SHOW USER.
I have let Rob know in case he wasn't aware of that.
I did see that; I suspect it's the new firewall not properly
maintaining the source address as it forwards the connection.
--
-- Rob
Arne Vajhøj
2020-08-31 16:47:02 UTC
Permalink
Post by Robert A. Brooks
Post by Simon Clubley
Post by Hunter Goatley
EISNER is back online! The IP address has changed, but the change to
eisner.decus.org seems to have propagated now, so you shouldn't have any
trouble logging in.
All seems to be OK, but let me know if you see anything unusual.
I have noticed that everyone gets the same VMS-visible IP address now
in SHOW USER.
I have let Rob know in case he wasn't aware of that.
I did see that; I suspect it's the new firewall not properly
maintaining the source address as it forwards the connection.
Can it do that?

HTTP supports X-Forwarded-For.

Does telnet/ssh support anything similar??

Arne
Simon Clubley
2020-09-01 18:27:01 UTC
Permalink
Post by Arne Vajhøj
Post by Robert A. Brooks
I did see that; I suspect it's the new firewall not properly
maintaining the source address as it forwards the connection.
Can it do that?
Yes, if the firewall handles this correctly. That information is in the
IP header, which is not encrypted in a SSH session.
Post by Arne Vajhøj
HTTP supports X-Forwarded-For.
Which is as trustworthy as the machine which inserted that header. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2020-09-01 19:55:45 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Robert A. Brooks
I did see that; I suspect it's the new firewall not properly
maintaining the source address as it forwards the connection.
Can it do that?
Yes, if the firewall handles this correctly. That information is in the
IP header, which is not encrypted in a SSH session.
The source IP address in the IP header should contain
the IP address of the inside of firewall. That is how NAT works.
Post by Simon Clubley
Post by Arne Vajhøj
HTTP supports X-Forwarded-For.
Which is as trustworthy as the machine which inserted that header. :-)
True, but the firewall is usually setup by the same
entity that mange the server.

Arne
Simon Clubley
2020-09-02 12:11:11 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Post by Robert A. Brooks
I did see that; I suspect it's the new firewall not properly
maintaining the source address as it forwards the connection.
Can it do that?
Yes, if the firewall handles this correctly. That information is in the
IP header, which is not encrypted in a SSH session.
The source IP address in the IP header should contain
the IP address of the inside of firewall. That is how NAT works.
What makes you say that ?

Don't assume that all NAT implementations are the same.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2020-09-02 12:36:11 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Post by Robert A. Brooks
I did see that; I suspect it's the new firewall not properly
maintaining the source address as it forwards the connection.
Can it do that?
Yes, if the firewall handles this correctly. That information is in the
IP header, which is not encrypted in a SSH session.
The source IP address in the IP header should contain
the IP address of the inside of firewall. That is how NAT works.
What makes you say that ?
Don't assume that all NAT implementations are the same.
Responses need to be able to find the firewall.

But I guess that should be handled by making the firewall
the default router.

So you are probably right.

Arne
Stephen Hoffman
2020-09-02 18:26:15 UTC
Permalink
Post by Simon Clubley
Yes, if the firewall handles this correctly. That information is in the
IP header, which is not encrypted in a SSH session.
The source IP address in the IP header should contain the IP address of
the inside of firewall. That is how NAT works.
That's one way that a NAT device can be configured, yes.

Source IP address pass-through is quite commonly configured within many
networks, and pretty much any NAT device will support that.

This is one such case where source address pass-through is necessary, too.
Post by Simon Clubley
Post by Arne Vajhøj
HTTP supports X-Forwarded-For.
Which is as trustworthy as the machine which inserted that header. :-)
True, but the firewall is usually setup by the same entity that mange
the server.
The recipient firewall has no access to the HTTP headers within HTTPS
traffic, short of moving the receiving server's keys out to the
firewall.
--
Pure Personal Opinion | HoffmanLabs LLC
Hunter Goatley
2020-08-31 18:34:31 UTC
Permalink
Post by Simon Clubley
I have noticed that everyone gets the same VMS-visible IP address now
in SHOW USER.
I have let Rob know in case he wasn't aware of that.
I did the same thing this morning, as I didn't see your post until now.
Post by Simon Clubley
Do you have any scripts or programs running on Eisner itself which block
connections based on source IP address as seen by VMS or which do spam
scoring based on the client's IP address ?
SSH and PMAS both use IP addresses to block connections for repeat AUTH
failure offenders. Those checks are currently broken.

And no, there's no mechanism for passing the original IP address as
there is with HTTP.

I'm pretty sure we had this same problem when VSI first took over
hosting EISNER. It was some firewall adjustment that needed to be made.
The network team at VSI knows about the issue, but they're dealing with
a lot of issues, so I'm not sure how long it'll be before it's fixed.
--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
***@goatley.com http://hunter.goatley.com/
Jan-Erik Söderholm
2020-08-31 07:32:03 UTC
Permalink
Post by Hunter Goatley
Post by Simon Clubley
Eisner is on the move again.
VSI are moving most of their systems to a co-location facility and
Eisner will not be available for the next few days after it is shutdown
some time on Thursday.
EISNER is back online! The IP address has changed, but the change to
eisner.decus.org seems to have propagated now, so you shouldn't have any
trouble logging in.
All seems to be OK, but let me know if you see anything unusual.
Thanks to Rob for getting EISNER relocated and back up!
The last mail I've got about the re-location said:

"The VMS SFTP server, vsiftp.vmssoftware.com, is moving to a new data
center. The server will be unavailable starting at 5 AM Friday August 28
US Eastern Daylight Saving Time. The server is planned to be available
on Saturday August 29..."

Now, I tried on late Sunday evening also, but no access. Right now (Monday
morning) vsiftp.vmssoftware.com seems to be back online. I do not think
timezons should make that large difference, from Saturday to Monday...
Loading...