Hello,
After starting SLES 11 SP3 or SP4 instances in AWS (region eu-central-1), the suse_register executed during cloud-init is not working.
The error from /root/.suse_register.log returned after the send to https://smt-ec2.susecloud.net/center/regsvc?command=register…
HTTP/1.1 500 Internal Server Error
…
Error message:
Apache2::Filter::get_brigade: (70007) The timeout specified has expired at /usr/lib/perl5/vendor_perl/5.10.0/SMT/Utils.pm line 299
As the result, there are no repositories registered (except the NVidia) and it’s impossible to install any software.
Thanks in advance for your help,
Guillaume
Hi,
It works for me, can you provide the output form
grep smt /etc/hosts
Thanks,
Robert
Hi,
The output is
54.93.130.182 smt-ec2.susecloud.net smt-ec2
I’ve executed the suse_register command with debug parameters (suse_register -d3 -i -L <path_to_log>) and it seems to communicate correctly.
I can see certificate validation then retrieving a list of products, then the client send the register command and receive the Internal Error.
Regards,
Guillaume
You put me in the right direction.
I’ve tried changing the IP address in the /etc/hosts:
So it seems to be a problem with both Frankfurt SMT servers.
It still a problem for us as we want to deploy multiple instances automatically with CloudFormation in the Frankfurt region, and the instance came initialized with the Frankfurt SMT.
Regards,
Guillaume
[QUOTE=gbouzebra;32279]Hi,
The output is
54.93.130.182 smt-ec2.susecloud.net smt-ec2
I’ve executed the suse_register command with debug parameters (suse_register -d3 -i -L <path_to_log>) and it seems to communicate correctly.
I can see certificate validation then retrieving a list of products, then the client send the register command and receive the Internal Error.
Regards,
Guillaume[/QUOTE]
Executing suse_register command directly is not supported. The use of the command does not provide the proper information to the update server and thus registration will fail.
What is the ami-ID of the image that was used to launch the instance?
To better understand what is going on please clear /var/log/cloudregister then run /usr/sbin/registercloudguest --force-new.
If you do not get the repositories run
/usr/bin/ec2metadata --api latest --document --signature --pkcs7 --xml >& instanceInfo.txt
and then please pack up
/var/log/cloudregister
/etc/hosts
instanceInfo.txt
into a tarball and upload it to:
ftp://ftp.novell.com/incoming
i.e.
ftp ftp.novell.com
LOGIN as anonymous and provide your e-mail as password
cd incoming
put THE_NAME_OF_THE_TARBALL
Let us know when you uploaded the tarball and provide the name.
[QUOTE=gbouzebra;32283]You put me in the right direction.
I’ve tried changing the IP address in the /etc/hosts:
So it seems to be a problem with both Frankfurt SMT servers.
It still a problem for us as we want to deploy multiple instances automatically with CloudFormation in the Frankfurt region, and the instance came initialized with the Frankfurt SMT.
Regards,
Guillaume[/QUOTE]
Where did you get the idea to go across regions? That certainly puts you in undefined territory.
It was only to try to identify from where the issue was coming. Now AWS Business support redirected me here as they say it’s probably related to the SMT server itself and they cannot do anyhing on their side. But I don’t keep instances activated “across regions”. It was just a test.
gbouzebra_register_info.tar has been uploaded.
Guillaume
The image you are using is the latest image, which is also the one I have been using for testing and am unable to reproduce the problem. Further the data you provided looks as expected, except for the failure of course.
Are you launching the instance in a VPC where the instance does not get a public IP address? If yes, then that would be the problem. Please see https://www.suse.com/communities/blog/using-suse-linux-enterprise-demand-aws-vpc-setup/ for information about configuring the VPC to get access to the repos.
Yes, I’m in a VPC and don’t have a public IP. I have already followed the blog few days agi and we have quiet standard setup with a NAT instance. AWS support confirmed everything is flowing nicely from a network perspective. And as I get the repos when registering with another region SMT, is it an indication? Frankly we are quiet lost and unable to start our planned workload…
Regards,
Guillaume
[QUOTE=gbouzebra;32321]Yes, I’m in a VPC and don’t have a public IP. I have already followed the blog few days agi and we have quiet standard setup with a NAT instance. AWS support confirmed everything is flowing nicely from a network perspective. And as I get the repos when registering with another region SMT, is it an indication? Frankly we are quiet lost and unable to start our planned workload…
Regards,
Guillaume[/QUOTE]
Sorry for the trouble. At this point this doesn’t quite make sense yet. What is the public IP of the NAT instance. I’ll see if I can find anything in the logs on the server.
OK,
I found the IP in the logs. We are getting a timeout on the server when we are trying to access information from the request. Would you mind to try stopping the NAT instance and using a VPC-Gateway? I am wondering if the NAT does something odd with the http request.
I tried with a VPC NAT Gateway just now, but same error received (HTTP 500).
OK, will keep digging to try and figure out what is going on.
So I cheated a little and created a VPC that has everything wide open, i.e. has a 0.0.0.0/0 route that goes right through to the private subnet. With this setup the registration in the private subnet of an instance works as expected. Thus I would say the issue that is being observed is related to the routing table setup for the private subnet. Maybe we can get Amazon to take another look at that?
Our private subnet route table only contains 2 entries, the first one being the default route for the VPC:
<vpc_cidr> local
0.0.0.0/0 nat-instanceid
And a VPC issue would not explain why it is working with other EC2 SMT servers. But then it is working for you, so really strange…
You also have your private sub routed to a NAT instance or gateway?
Are there other things involved in the registration process than communication on the port 443?
I was using a NAT GW in my test.
Successful registration requires both port 443 and port 80, i.e. there is http and https traffic.
All update servers are configured the same way. The server do send messages back to the client. Given that I see a timeout on the server it appears that there may be an issue with the return route.