Mark, I went through everything you gave me(through VM) and it still fails. I
an wait for the network team to answer your question if it is Vlan aware and
layer2/3. I did ask one of the server guys and he seems to think layer 3.
Anyway here is the output form the commands you gave me. I'm not
Thanks, to everyone for their responses.
I hope the procedure can be made alot simpler if I was to use zipl.conf
and the dasd=- parm.
Does anyone know if that would make the change easier??
or
Does anyone know, if with SLES10, this procedure is different and/or
easier??
Also, does my
During SLES installation we get messages about key generation and key
fingerprints and the public/private key pairs. Suppose we're cloning
this server, what should I be doing to rework the keys and
fingerprints and key pairs such that no two servers appear similar?
Hi,
To regenerate new SSH keys in 3 steps :
# Create a backup dir
mkdir -p /etc/ssh/backup
# Move ssh_host_dsa_key, ssh_host_dsa_key.pub, ssh_host_key,
ssh_host_key.pub,
# ssh_host_rsa_key and ssh_host_rsa_key.pub to the backup dir
mv /etc/ssh/ssh_host* /etc/ssh/backup
# Restart SSH
On Thursday 20 November 2008 13:34, Scully, William P wrote:
During SLES installation we get messages about key generation and key
fingerprints and the public/private key pairs. Suppose we're cloning
this server, what should I be doing to rework the keys and
fingerprints and key pairs such that
Greetings all,
I am having a problem configuring VIPA on SLES9 Linux on z. I think the
problem is a mismatch in MTU sizes between out VIPA OSA definitions and
the dummy device we create. For some reason, we can only have a max MTU
size of 1500 on the dummy device and the real OSA is 8992
On 11/20/2008 at 5:19 PM, Slavick, Jack H [EMAIL PROTECTED] wrote:
I am having a problem configuring VIPA on SLES9 Linux on z. I think the
problem is a mismatch in MTU sizes between out VIPA OSA definitions and
the dummy device we create. For some reason, we can only have a max MTU
size of
Rich Smrcina wrote:
Interesting. That sort of smacks in the face of all reasonableness.
I really like this para:
Here we have a clear-cut winner. The LVM ran 30% faster, achieved a 25%
higher transaction per second rate, scored 56% faster on kilobytes per
second and had a 108% better average
