Why don't you use the bootstrap script for those clients? It's really easy to copy the template and plugin the few pieces of information you need to get it to work for your environment. In my environment I have several spanning RHEL, Scientific Linux CentOS and soon Oracle Linux (yuck) for a multi-org environment.

That said the bootstrap scripts could use some enhancement and I've been thinking about writing a RFE laying out what's needed.
Simply stated there should be a web page to generate them for specific distros and activation keys.
Further more the base packages it installs to get the registration to work should come from the distro specific base and the spacewalk client repo for that distro instead of thr RHEL version which is its builtin behavior like the kickstarts attempt to do as well.  I've implemented a hack in mine to do that but it should be configurable via the Web page in a similar manner to kickstarts. Incidentally the kickstarts are where I get the URI for the correct repos on the spacewalk server and they don't require authentication.

I think I get what you are doing with the vhost it's similar to what a lot of people do with mrepo but you can do it with a directory instead of a vhost and there are a few components of spacewalk that at least historically don't interact with other vhosts‎ on the same box. I also do something similar with ISOs mounted on a loopback and a directory statement in my apache config to initially populate new versions of distros into spacewalk.

That is unless I have it all wrong and you are spoofing the DNS domains for the public yum repos to redirect them to your box.


Sent from my BlackBerry 10 smartphone.
From: Joe Belliveau
Sent: Monday, January 19, 2015 17:57
Subject: Re: [Spacewalk-list] general inquiry about client install/registration

The host sits on a squid proxy, I rsync just the repos i need from epel and only allow that specific url to pass from the web server. spacewalk uses the proxy as well. However my spacewalk servers are all linked to each other… so only 1 has internet access to retrieve packages… matter of fact the one only reach out to a specific redhat server to pull patches. the web server hosting the epel packages are not on spacewalk… they reside on one of my corporate web servers and its a simple host to a locked folder.

Every host in my infrastructure does not see the outside world at all. This is why we use spacewalk and spacewalk slaves.

Every aspect is controlled.. I hardly think medical environments are as heavily scrutinized as financial institutions but I have never dealt with many fins.

the vhost is just a redirect to a locked up folder, it makes it easier to setup and also makes it easier for systems that do not have all packages installed… when we purchase redhat based appliances we rely heavily on getting spacewalk access to these hosts, for reporting back to the vendors. A simple yum repo file and we can easily install the packages we need to get spacewalk on the host.

Again this is my environment and has worked quite well for us. What works for me may not work for you. But Im just giving the user who asked a simple solution.

—Joe

On Jan 19, 2015, at 5:14 PM, [email protected] wrote:

I've worked for two stock exchanges, ‎I've done infosec for several banks and currently work in a mission critical environment where a large portion of my job is infosec and there is a fairly high probability if I can set the time aside that I will get a CISP cert this year. None of my production servers except for my spacewalk servers are in a isolated vlan which has outbound internet access that is only to natted private IPs. Furthermore when I worked for the stock exchanges our satellite servers went through a squid proxy which limited them to specific URI's and virus scanned all traffic.  so I really do understand security but again I'm failing to understand the requirement and even so the whole adding a vhost to the spacewalk server is superfluous and in the case of spacewalk may cause problems.

If some one can give a full explanation of the specific security concerns and requirements I can suggest ‎several ranging from simple to more elaborate methods for handling them which have been tested and follow best practices appropriate to the environment.

By the way rsync won't work with the spacewalk repos you need to use wget recursively "-r" instead

Sent from my BlackBerry 10 smartphone.
From: Brian Kinney
Sent: Monday, January 19, 2015 15:00
Subject: Re: [Spacewalk-list] general inquiry about client install/registration

I have to agree with Joe here.
I am not overly security paranoid, but I’d plan to lock down the OS deployment/patch services for 90% of the servers in my company too – whether or not I had a gov’t contract to protect.  Also, I am not finding this a “complicated solution.”    After working for a banking system, this is comparatively trivial. 

 

Brian

 

 

From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Monday, January 19, 2015 10:49 AM
To: [email protected]; [email protected]
Subject: Re: [Spacewalk-list] general inquiry about client install/registration

 

Wow you guys do like complicated solutions why not just put the repo in a subdirectory of /pub off the docroot ‎spacewalk doesn't password protect that directly off the webserver for just such uses.


Just to be clear what repos precisely are you intending to mirror? Server, client, EPEL or what?

 

Sent from my BlackBerry 10 smartphone.
From: Joe Belliveau
Sent: Monday, January 19, 2015 12:38
Subject: Re: [Spacewalk-list] general inquiry about client install/registration

 

Also here is another one. if you want to use nfs as well.

 

 

 

Sounds great!  Never built a mirror like this.  Any suggestions/URLs where a quality example could be found?

 

Brian

 

This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it.  We use reasonable measures to virus scan all E-mails leaving UNICOM Global but no warranty is given that this E-mail and any attachments are virus free. You should ensure you have adequate measures in place for your own virus checking.

 

From: [email protected] [mailto:[email protected]] On Behalf Of Joe Belliveau
Sent: Monday, January 19, 2015 5:52 AM
To: [email protected]
Subject: Re: [Spacewalk-list] general inquiry about client install/registration

 

This can be done easily.

 

I mirror the packages to a local apache redirect on the spacewalk server… 

 

It can easily be done.

 

—Joe

 

 

On Jan 19, 2015, at 8:32 AM, Edsall, William (WJ) <[email protected]> wrote:

 

Hello list,

Just a general question about clients. 

 

One reason for my investigation into satellite/spacewalk is due to network security and lack of internet access to our linux machines. I was surprised when the spacewalk documentation mentioned external yum installs in order to get spacewalk ready; was really hoping this was done 100% internal with the spacewalk server.

 

So my question is – what’s the best practice to move everything internal? Can it be done? Should I look further into the bootstrap procedure?

 

 

 

Thanks,

William

 

_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list

 

_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list

 





_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list


_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list
_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list

Reply via email to