Menu
▾
▴
linuxcoe-users — List for LinuxCOE users to discuss anything LinuxCOE related
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|
From: Satoru F. <fu...@os...> - 2011-12-28 10:02:18
|
Hi all, I'd like to create image of Ubuntu Oneiric, so I downloaded latest version of SystemDesigner-Ubuntu from http://linuxcoe.cvs.sourceforge.net/viewvc/linuxcoe/SystemDesigner-Ubuntu/ Then install as instructed, but got an error at below; # ./autogen.sh # ./configure prefix=/usr/local/linuxcoe-sd # make install make: *** No rule to make target `depots/apt-Ubuntu-Oneiric', needed by `all-am'. Stop. Any ideas to solve it? Thanks and regards, Satoru Funai |
|
From: Satoru F. <fu...@os...> - 2011-12-11 01:51:18
|
Hi Bryan, Thanks for your reply. I found that installed package from OpenQRM was old, so I downloaded newer version of SystemDesigner-CentOS repo and installed. Then it works fine! BTW, do you have a plan to support VMware vSphere ESX 4.1/5.0? I found VMwareESX support in beta and only still 3.5. Best regards, Satoru Funai ------------------------------------------ > Satoru > > On Fri, Dec 09, 2011 at 03:20:39AM -0600, Satoru Funai wrote: > > I'm new to LinuxCOE, just installed on my ubuntu10.4 server withHi Bri > > OpenQRM4.9 successfully. > > Welcome :) > > Is it fair to assume that the OpenQRM based install used the > packages available from the project? > > > Then to make a boot image from System Designer GUI, but there is no > > menu to create CentOS 6 image. > > I found CentOS6 snapshot on > > http://www.instalinux.com/snapshots/images/ and download it, but I > > don't understand how to add it to System Designer create menu. > > Yes you are correct in that the codebase and images do support > CentOS 6, however the packages are a bit behind.. > > > Does anyone point it out please? > > You have a couple of options: > > grab the necessary bits from the SystemDesigner-CentOS repo > wait just a bit and I'll try to gen more up-to-date packages > > If you opt for the former, just let me know and I can provide > more details. If the latter, check the packages repo in a > day or so and update to those versions, > > > Thanks in advance and regards, > > HTH, > > byrang > > > ------------------------------------------------------------------------------ > > Cloud Services Checklist: Pricing and Packaging Optimization > > This white paper is intended to serve as a reference, checklist and > > point of > > discussion for anyone considering optimizing the pricing and > > packaging model > > of a cloud services business. Read Now! > > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > > _______________________________________________ > > Linuxcoe-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxcoe-users > |
|
From: Bryan G. <Bry...@HP...> - 2011-12-10 16:21:55
|
Satoru On Fri, Dec 09, 2011 at 03:20:39AM -0600, Satoru Funai wrote: > I'm new to LinuxCOE, just installed on my ubuntu10.4 server with OpenQRM4.9 successfully. Welcome :) Is it fair to assume that the OpenQRM based install used the packages available from the project? > Then to make a boot image from System Designer GUI, but there is no menu to create CentOS 6 image. > I found CentOS6 snapshot on http://www.instalinux.com/snapshots/images/ and download it, but I don't understand how to add it to System Designer create menu. Yes you are correct in that the codebase and images do support CentOS 6, however the packages are a bit behind.. > Does anyone point it out please? You have a couple of options: grab the necessary bits from the SystemDesigner-CentOS repo wait just a bit and I'll try to gen more up-to-date packages If you opt for the former, just let me know and I can provide more details. If the latter, check the packages repo in a day or so and update to those versions, > Thanks in advance and regards, HTH, byrang > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > _______________________________________________ > Linuxcoe-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxcoe-users |
|
From: Satoru F. <fu...@os...> - 2011-12-09 09:40:00
|
Hi All, I'm new to LinuxCOE, just installed on my ubuntu10.4 server with OpenQRM4.9 successfully. Then to make a boot image from System Designer GUI, but there is no menu to create CentOS 6 image. I found CentOS6 snapshot on http://www.instalinux.com/snapshots/images/ and download it, but I don't understand how to add it to System Designer create menu. Does anyone point it out please? Thanks in advance and regards, Satoru Funai |
|
From: Bryan G. <bry...@hp...> - 2010-12-17 02:51:26
|
Lee, On Fri, Dec 17, 2010 at 12:37:30AM +0000, Mayes, Lee wrote: > Another followup: John also noted his Maverick install was ignoring the preseed entries for installation source and going after the UK Ubuntu mirror as if it was hardcoded in the installer. That does seem to be the case, I've duped it. There's an open bug against 10.10: > > https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/659632 Yup, tis the reason we've yet to move Maverick out of our testing space :/ > If anyone has any workaround ideas I'm all ears. Have yet to find/hear of one, either, bryang |
|
From: Mayes, L. <lee...@hp...> - 2010-12-17 00:39:08
|
Another followup: John also noted his Maverick install was ignoring the preseed entries for installation source and going after the UK Ubuntu mirror as if it was hardcoded in the installer. That does seem to be the case, I've duped it. There's an open bug against 10.10: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/659632 If anyone has any workaround ideas I'm all ears. Best Regards, Lee |
|
From: Mayes, L. <lee...@hp...> - 2010-12-16 19:43:36
|
John and I took this offline and we found the issue with the post install deb not installing. The permissions on base/PRE-DEB made it unreadable by apache. Since the 3 BASE snippets are not required/mandatory files system-designer treated it as a no-show and completed creating the image without it defined. John tweaked permissions on the file and now the post install environment is working. Lee -----Original Message----- From: Cusick, John CTR NAWCWD, 541400D [mailto:joh...@na...] Sent: Wednesday, December 15, 2010 6:26 PM To: Mayes, Lee; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors Lee, Yes, sorry, I forgot to give you the info on that. Instead of including it all, here are the relevant parts: ------ Scroll down to ===START=== for the real action. Found installed product acpi-support - 0.137 Found ... Found ... Found installed product linux-sound-base - 1.0.23+dfsg-1ubuntu4 Found installed product lksctp-tools - 1.0.11+dfsg+1 Found... Found installed product zlib1g - 1:1.2.3.4.dfsg-3ubuntu1 ===START=== My waystation is ubuntu-lds.def.ghi.mil (the proper waystation name) --------- That's all, nothing more, so it would appear that the /opt/LinuxCOE/bin LinuxCOE_final script never executed past printing the waystation. There were no entries in the init.d directory. I placed the linuxcoe-sw-sources deb in the root of the html directory /var/www and my $PREFIX/etc/base/POST-DEB file references that location, re: the example in yesterday's email. I can plug that url/file into any browser on the network and get it (I double-checked, in case there were resolver or permission problems). During the install, I also pinged the waystation from the system being installed while it was installing (from terminal 2) by name to make sure it was resolving properly, no problem there. I wasn't sure if I needed to set up a specific addon bundle for the linuxcoe-sw-sources deb, per yesterday's example, and so I have not done that. If that is also necessary then I also assume I have to setup a "local" repo and add that to my repo lists, if that is the way the Bundle system is designed... ?? After reading some of the source and yesterday's email I was thinking that a specific bundle entry was not necessary since the scripts uses wget && dpkg -I to fetch and install the package, but now that I'm reading the LinuxCOE-final script... again... am I'm wrong there? Since I have not fully wrapped my head around this, though, I'm still am a little confused as to what the POST-DEB/linuxcoe-sw-sources stuff will do. It seems like it ends up handling updates/packages after the fact (assuming POST means after the installation is complete, of course) and not handle pulling everything from my mirror instead of a public mirror from the very beginning. The preseed, by the way, seems correct, too: d-i mirror/http/hostname string ubuntu-lds.def.ghi.mil Which makes me think there is a resolv issue. But I checked that... as well as I know how, anyway. Maybe I should try using the server ip address instead of the name? (By the way, I tested this out with my rpm-based LinuxCOE server (ver 4.2), separate from the deb-based system to keep things as simple as possible, and that worked great. I/LinuxCOE installed, from boot to desktop login, Fedora 13 in approx. 20 minutes, and this on a local usb drive VM hanging off my laptop. Once this is tuned up, I figure a new-to-linux sys admin can set up a basic and mostly secured workstation in less than an hour. Beautiful!) Regards, John C -----Original Message----- From: Mayes, Lee [mailto:lee...@hp...] Sent: Wednesday, December 15, 2010 14:18 To: Cusick, John CTR NAWCWD, 541400D; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors Hi John, On the client there should be /var/log/LinuxCOE-* logs to tell you what transpired when it post-processing attempted to kick in. Lee -----Original Message----- From: Cusick, John CTR NAWCWD, 541400D [mailto:joh...@na...] Sent: Wednesday, December 15, 2010 2:19 PM To: Mayes, Lee; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors Lee, Success, up to a point with your directions below. I've built the deb using EPM (straight out of the sourceforge box - haven't read the EPM docs yet). The LinuxCOE stuff was created on the client as follows /opt/LinuxCOE/bin/ /opt/LinuxCOE/bin/LinuxCOE-final and /etc/opt/LinuxCOE/INSTALLED /etc/opt/LinuxCOE/replay /etc/opt/LinuxCOE/waystation (my waystation is listed) /etc/opt/LinuxCOE/apt/ (empty) /etc/opt/apt.sources/COE_BASE (with my individual repos - similar to yours below) I noticed that none of the three bin scripts from (in my case) linuxcoe-sw-sources-4.0-0-linux-2.6-all.deb were there, though. Should they be? After reading reading the perl scripts it looks to me like the should, for example the configure_apt script. POST-DEB is setup as you have it below, modded for my system, of course. The system still loaded completely from outside mirrors. John C. -----Original Message----- From: Mayes, Lee [mailto:lee...@hp...] Sent: Tuesday, December 14, 2010 5:38 To: Cusick, John CTR NAWCWD, 541400D; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors Hi John, What you want to do is certainly do-able and is how we run our shop as well. While there is nothing proprietary about our post processing environment it's probably not our best documented feature even though we live and die by it on our internal System Designer instance. In the older days Deb/Ubuntu did the right thing automatically, whatever value you preseeded with was what ended up in sources.list but that appears to no longer be the case. The LinuxCOE post-processing environment runs in 4 stages, we call them PRE, MID, POST and the bundle installer proper. You'll need to make a couple of changes to enable it. In your $PREFIX/linuxcoe.rc file, comment out (or set to 0) the NO_COE directive. This tells the image generation scripts that you desire LinuxCOE post processing and they will append the bootstrap that calls it to your %final script. If folks are currently using your system designer instance and you want to test/debug this functionality alongside but without touching your existing deployments, create the file $PREFIX/COE containing the single line 'NO_COE 0' (without quotes) and append ?defs=COE to your URLs, for example http://your_server/systemdesigner-cgi-bin/coe_bootimage?defs=COE . when you use ?defs= on the URLs, it parses the standard linuxcoe.rc first and then another file overriding any values you've redefined. We use this not only for testing but to give some internal customers a custom view. The post processing 'bootstrap' code it will append to your final script can be seen in the $PREFIX/data/*_final_skel files. These skel files are written to layer any post processing needs onto a system in 3 stages. On rpm based systems it runs a straight rpm -i @METHOD@/@WAYSTATION@/whatever.rpm kind of thing, on deb based system it will wget && dpkg -I the files. The sole intention of the first 3 stages is to configure apt/yum/up2date/etc. to point at internal waystations and to deliver the LinuxCOE bundle installer. If there you have ADDONS defined and chose custom bundles during image creation, a 4 step is called that would install this software using APT || YUM depending on distro now that it's configured to point at your waystation. If you're simply wanting to ensure your servers end up pointed at your standard mirrors, you'll only need to install the deb that configures APT on the clients to point back at you. The post processing stuff is on sf here: http://linuxcoe.cvs.sourceforge.net/viewvc/linuxcoe/postproc/ http://linuxcoe.cvs.sourceforge.net/viewvc/linuxcoe/postproc/deb/apt-config/linux-2.6-all/linuxcoe-sw-sources-4.0-linux-2.6-all.deb?revision=1.1.1.1 - oops, I accidentally checked in the .deb vs. just source for it. :^) I started using EPM to do my packaging a long time ago when I supported HPUX and Linux since I'm lazy and I only had to learn one packaging meta-language. That's the 'format' of this check-in. You can apt-get install epm, its home is http://www.epmhome.org/ . You'll want to build linuxcoe-sw.deb and export somewhere on your waystation. Then create the file $PREFIX/base/POST-DEB, here's our's for an example: hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/base> cat POST-DEB @ME...@li.../LinuxCOE/COE/3.1/packages/DEBS/linuxcoe-sw-sources-4.0.all.deb hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/base> The typical @METHOD@/@WAYSTATION@/etc. will get sub/replaced. This will be pulled in with a wget/dpkg -i. The last piece to configure tells the linuxcoe-sw-sources.deb what to replace the distro's default apt configuration with. That's done in $PREFIX/depots/, here's our Maverick example: hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/depots> cat apt-Ubuntu-Maverick # core distro deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick main restricted # additional goodies # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick universe multiverse # updates deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates main restricted # additional updates (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates universe multiverse # security deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security main restricted # additional security (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security universe multiverse # backports #deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports main restricted #deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports main restricted # additional backports (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports universe multiverse # proposed #deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed main restricted #deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed main restricted # additional proposed (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed universe multiverse hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/depots> I realize this is a lot to digest and kind of rambling but give a whirl and see what you end up with. All of the post processing leaves its logfiles at /var/log/LinuxCOE-* on the installing system. Bryan and I will be happy to help. Best Regards, Lee |
|
From: Cusick, J. C. N. 5. <joh...@na...> - 2010-12-15 23:27:16
|
Lee, Yes, sorry, I forgot to give you the info on that. Instead of including it all, here are the relevant parts: ------ Scroll down to ===START=== for the real action. Found installed product acpi-support - 0.137 Found ... Found ... Found installed product linux-sound-base - 1.0.23+dfsg-1ubuntu4 Found installed product lksctp-tools - 1.0.11+dfsg+1 Found... Found installed product zlib1g - 1:1.2.3.4.dfsg-3ubuntu1 ===START=== My waystation is ubuntu-lds.def.ghi.mil (the proper waystation name) --------- That's all, nothing more, so it would appear that the /opt/LinuxCOE/bin LinuxCOE_final script never executed past printing the waystation. There were no entries in the init.d directory. I placed the linuxcoe-sw-sources deb in the root of the html directory /var/www and my $PREFIX/etc/base/POST-DEB file references that location, re: the example in yesterday's email. I can plug that url/file into any browser on the network and get it (I double-checked, in case there were resolver or permission problems). During the install, I also pinged the waystation from the system being installed while it was installing (from terminal 2) by name to make sure it was resolving properly, no problem there. I wasn't sure if I needed to set up a specific addon bundle for the linuxcoe-sw-sources deb, per yesterday's example, and so I have not done that. If that is also necessary then I also assume I have to setup a "local" repo and add that to my repo lists, if that is the way the Bundle system is designed... ?? After reading some of the source and yesterday's email I was thinking that a specific bundle entry was not necessary since the scripts uses wget && dpkg -I to fetch and install the package, but now that I'm reading the LinuxCOE-final script... again... am I'm wrong there? Since I have not fully wrapped my head around this, though, I'm still am a little confused as to what the POST-DEB/linuxcoe-sw-sources stuff will do. It seems like it ends up handling updates/packages after the fact (assuming POST means after the installation is complete, of course) and not handle pulling everything from my mirror instead of a public mirror from the very beginning. The preseed, by the way, seems correct, too: d-i mirror/http/hostname string ubuntu-lds.def.ghi.mil Which makes me think there is a resolv issue. But I checked that... as well as I know how, anyway. Maybe I should try using the server ip address instead of the name? (By the way, I tested this out with my rpm-based LinuxCOE server (ver 4.2), separate from the deb-based system to keep things as simple as possible, and that worked great. I/LinuxCOE installed, from boot to desktop login, Fedora 13 in approx. 20 minutes, and this on a local usb drive VM hanging off my laptop. Once this is tuned up, I figure a new-to-linux sys admin can set up a basic and mostly secured workstation in less than an hour. Beautiful!) Regards, John C -----Original Message----- From: Mayes, Lee [mailto:lee...@hp...] Sent: Wednesday, December 15, 2010 14:18 To: Cusick, John CTR NAWCWD, 541400D; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors Hi John, On the client there should be /var/log/LinuxCOE-* logs to tell you what transpired when it post-processing attempted to kick in. Lee -----Original Message----- From: Cusick, John CTR NAWCWD, 541400D [mailto:joh...@na...] Sent: Wednesday, December 15, 2010 2:19 PM To: Mayes, Lee; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors Lee, Success, up to a point with your directions below. I've built the deb using EPM (straight out of the sourceforge box - haven't read the EPM docs yet). The LinuxCOE stuff was created on the client as follows /opt/LinuxCOE/bin/ /opt/LinuxCOE/bin/LinuxCOE-final and /etc/opt/LinuxCOE/INSTALLED /etc/opt/LinuxCOE/replay /etc/opt/LinuxCOE/waystation (my waystation is listed) /etc/opt/LinuxCOE/apt/ (empty) /etc/opt/apt.sources/COE_BASE (with my individual repos - similar to yours below) I noticed that none of the three bin scripts from (in my case) linuxcoe-sw-sources-4.0-0-linux-2.6-all.deb were there, though. Should they be? After reading reading the perl scripts it looks to me like the should, for example the configure_apt script. POST-DEB is setup as you have it below, modded for my system, of course. The system still loaded completely from outside mirrors. John C. -----Original Message----- From: Mayes, Lee [mailto:lee...@hp...] Sent: Tuesday, December 14, 2010 5:38 To: Cusick, John CTR NAWCWD, 541400D; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors Hi John, What you want to do is certainly do-able and is how we run our shop as well. While there is nothing proprietary about our post processing environment it's probably not our best documented feature even though we live and die by it on our internal System Designer instance. In the older days Deb/Ubuntu did the right thing automatically, whatever value you preseeded with was what ended up in sources.list but that appears to no longer be the case. The LinuxCOE post-processing environment runs in 4 stages, we call them PRE, MID, POST and the bundle installer proper. You'll need to make a couple of changes to enable it. In your $PREFIX/linuxcoe.rc file, comment out (or set to 0) the NO_COE directive. This tells the image generation scripts that you desire LinuxCOE post processing and they will append the bootstrap that calls it to your %final script. If folks are currently using your system designer instance and you want to test/debug this functionality alongside but without touching your existing deployments, create the file $PREFIX/COE containing the single line 'NO_COE 0' (without quotes) and append ?defs=COE to your URLs, for example http://your_server/systemdesigner-cgi-bin/coe_bootimage?defs=COE . when you use ?defs= on the URLs, it parses the standard linuxcoe.rc first and then another file overriding any values you've redefined. We use this not only for testing but to give some internal customers a custom view. The post processing 'bootstrap' code it will append to your final script can be seen in the $PREFIX/data/*_final_skel files. These skel files are written to layer any post processing needs onto a system in 3 stages. On rpm based systems it runs a straight rpm -i @METHOD@/@WAYSTATION@/whatever.rpm kind of thing, on deb based system it will wget && dpkg -I the files. The sole intention of the first 3 stages is to configure apt/yum/up2date/etc. to point at internal waystations and to deliver the LinuxCOE bundle installer. If there you have ADDONS defined and chose custom bundles during image creation, a 4 step is called that would install this software using APT || YUM depending on distro now that it's configured to point at your waystation. If you're simply wanting to ensure your servers end up pointed at your standard mirrors, you'll only need to install the deb that configures APT on the clients to point back at you. The post processing stuff is on sf here: http://linuxcoe.cvs.sourceforge.net/viewvc/linuxcoe/postproc/ http://linuxcoe.cvs.sourceforge.net/viewvc/linuxcoe/postproc/deb/apt-config/linux-2.6-all/linuxcoe-sw-sources-4.0-linux-2.6-all.deb?revision=1.1.1.1 - oops, I accidentally checked in the .deb vs. just source for it. :^) I started using EPM to do my packaging a long time ago when I supported HPUX and Linux since I'm lazy and I only had to learn one packaging meta-language. That's the 'format' of this check-in. You can apt-get install epm, its home is http://www.epmhome.org/ . You'll want to build linuxcoe-sw.deb and export somewhere on your waystation. Then create the file $PREFIX/base/POST-DEB, here's our's for an example: hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/base> cat POST-DEB @ME...@li.../LinuxCOE/COE/3.1/packages/DEBS/linuxcoe-sw-sources-4.0.all.deb hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/base> The typical @METHOD@/@WAYSTATION@/etc. will get sub/replaced. This will be pulled in with a wget/dpkg -i. The last piece to configure tells the linuxcoe-sw-sources.deb what to replace the distro's default apt configuration with. That's done in $PREFIX/depots/, here's our Maverick example: hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/depots> cat apt-Ubuntu-Maverick # core distro deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick main restricted # additional goodies # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick universe multiverse # updates deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates main restricted # additional updates (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates universe multiverse # security deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security main restricted # additional security (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security universe multiverse # backports #deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports main restricted #deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports main restricted # additional backports (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports universe multiverse # proposed #deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed main restricted #deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed main restricted # additional proposed (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed universe multiverse hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/depots> I realize this is a lot to digest and kind of rambling but give a whirl and see what you end up with. All of the post processing leaves its logfiles at /var/log/LinuxCOE-* on the installing system. Bryan and I will be happy to help. Best Regards, Lee |
|
From: Mayes, L. <lee...@hp...> - 2010-12-15 22:18:55
|
Hi John, On the client there should be /var/log/LinuxCOE-* logs to tell you what transpired when it post-processing attempted to kick in. Lee -----Original Message----- From: Cusick, John CTR NAWCWD, 541400D [mailto:joh...@na...] Sent: Wednesday, December 15, 2010 2:19 PM To: Mayes, Lee; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors Lee, Success, up to a point with your directions below. I've built the deb using EPM (straight out of the sourceforge box - haven't read the EPM docs yet). The LinuxCOE stuff was created on the client as follows /opt/LinuxCOE/bin/ /opt/LinuxCOE/bin/LinuxCOE-final and /etc/opt/LinuxCOE/INSTALLED /etc/opt/LinuxCOE/replay /etc/opt/LinuxCOE/waystation (my waystation is listed) /etc/opt/LinuxCOE/apt/ (empty) /etc/opt/apt.sources/COE_BASE (with my individual repos - similar to yours below) I noticed that none of the three bin scripts from (in my case) linuxcoe-sw-sources-4.0-0-linux-2.6-all.deb were there, though. Should they be? After reading reading the perl scripts it looks to me like the should, for example the configure_apt script. POST-DEB is setup as you have it below, modded for my system, of course. The system still loaded completely from outside mirrors. John C. -----Original Message----- From: Mayes, Lee [mailto:lee...@hp...] Sent: Tuesday, December 14, 2010 5:38 To: Cusick, John CTR NAWCWD, 541400D; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors Hi John, What you want to do is certainly do-able and is how we run our shop as well. While there is nothing proprietary about our post processing environment it's probably not our best documented feature even though we live and die by it on our internal System Designer instance. In the older days Deb/Ubuntu did the right thing automatically, whatever value you preseeded with was what ended up in sources.list but that appears to no longer be the case. The LinuxCOE post-processing environment runs in 4 stages, we call them PRE, MID, POST and the bundle installer proper. You'll need to make a couple of changes to enable it. In your $PREFIX/linuxcoe.rc file, comment out (or set to 0) the NO_COE directive. This tells the image generation scripts that you desire LinuxCOE post processing and they will append the bootstrap that calls it to your %final script. If folks are currently using your system designer instance and you want to test/debug this functionality alongside but without touching your existing deployments, create the file $PREFIX/COE containing the single line 'NO_COE 0' (without quotes) and append ?defs=COE to your URLs, for example http://your_server/systemdesigner-cgi-bin/coe_bootimage?defs=COE . when you use ?defs= on the URLs, it parses the standard linuxcoe.rc first and then another file overriding any values you've redefined. We use this not only for testing but to give some internal customers a custom view. The post processing 'bootstrap' code it will append to your final script can be seen in the $PREFIX/data/*_final_skel files. These skel files are written to layer any post processing needs onto a system in 3 stages. On rpm based systems it runs a straight rpm -i @METHOD@/@WAYSTATION@/whatever.rpm kind of thing, on deb based system it will wget && dpkg -I the files. The sole intention of the first 3 stages is to configure apt/yum/up2date/etc. to point at internal waystations and to deliver the LinuxCOE bundle installer. If there you have ADDONS defined and chose custom bundles during image creation, a 4 step is called that would install this software using APT || YUM depending on distro now that it's configured to point at your waystation. If you're simply wanting to ensure your servers end up pointed at your standard mirrors, you'll only need to install the deb that configures APT on the clients to point back at you. The post processing stuff is on sf here: http://linuxcoe.cvs.sourceforge.net/viewvc/linuxcoe/postproc/ http://linuxcoe.cvs.sourceforge.net/viewvc/linuxcoe/postproc/deb/apt-config/linux-2.6-all/linuxcoe-sw-sources-4.0-linux-2.6-all.deb?revision=1.1.1.1 - oops, I accidentally checked in the .deb vs. just source for it. :^) I started using EPM to do my packaging a long time ago when I supported HPUX and Linux since I'm lazy and I only had to learn one packaging meta-language. That's the 'format' of this check-in. You can apt-get install epm, its home is http://www.epmhome.org/ . You'll want to build linuxcoe-sw.deb and export somewhere on your waystation. Then create the file $PREFIX/base/POST-DEB, here's our's for an example: hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/base> cat POST-DEB @ME...@li.../LinuxCOE/COE/3.1/packages/DEBS/linuxcoe-sw-sources-4.0.all.deb hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/base> The typical @METHOD@/@WAYSTATION@/etc. will get sub/replaced. This will be pulled in with a wget/dpkg -i. The last piece to configure tells the linuxcoe-sw-sources.deb what to replace the distro's default apt configuration with. That's done in $PREFIX/depots/, here's our Maverick example: hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/depots> cat apt-Ubuntu-Maverick # core distro deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick main restricted # additional goodies # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick universe multiverse # updates deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates main restricted # additional updates (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates universe multiverse # security deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security main restricted # additional security (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security universe multiverse # backports #deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports main restricted #deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports main restricted # additional backports (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports universe multiverse # proposed #deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed main restricted #deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed main restricted # additional proposed (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed universe multiverse hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/depots> I realize this is a lot to digest and kind of rambling but give a whirl and see what you end up with. All of the post processing leaves its logfiles at /var/log/LinuxCOE-* on the installing system. Bryan and I will be happy to help. Best Regards, Lee |
|
From: Cusick, J. C. N. 5. <joh...@na...> - 2010-12-15 19:19:57
|
Lee, Success, up to a point with your directions below. I've built the deb using EPM (straight out of the sourceforge box - haven't read the EPM docs yet). The LinuxCOE stuff was created on the client as follows /opt/LinuxCOE/bin/ /opt/LinuxCOE/bin/LinuxCOE-final and /etc/opt/LinuxCOE/INSTALLED /etc/opt/LinuxCOE/replay /etc/opt/LinuxCOE/waystation (my waystation is listed) /etc/opt/LinuxCOE/apt/ (empty) /etc/opt/apt.sources/COE_BASE (with my individual repos - similar to yours below) I noticed that none of the three bin scripts from (in my case) linuxcoe-sw-sources-4.0-0-linux-2.6-all.deb were there, though. Should they be? After reading reading the perl scripts it looks to me like the should, for example the configure_apt script. POST-DEB is setup as you have it below, modded for my system, of course. The system still loaded completely from outside mirrors. John C. -----Original Message----- From: Mayes, Lee [mailto:lee...@hp...] Sent: Tuesday, December 14, 2010 5:38 To: Cusick, John CTR NAWCWD, 541400D; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors Hi John, What you want to do is certainly do-able and is how we run our shop as well. While there is nothing proprietary about our post processing environment it's probably not our best documented feature even though we live and die by it on our internal System Designer instance. In the older days Deb/Ubuntu did the right thing automatically, whatever value you preseeded with was what ended up in sources.list but that appears to no longer be the case. The LinuxCOE post-processing environment runs in 4 stages, we call them PRE, MID, POST and the bundle installer proper. You'll need to make a couple of changes to enable it. In your $PREFIX/linuxcoe.rc file, comment out (or set to 0) the NO_COE directive. This tells the image generation scripts that you desire LinuxCOE post processing and they will append the bootstrap that calls it to your %final script. If folks are currently using your system designer instance and you want to test/debug this functionality alongside but without touching your existing deployments, create the file $PREFIX/COE containing the single line 'NO_COE 0' (without quotes) and append ?defs=COE to your URLs, for example http://your_server/systemdesigner-cgi-bin/coe_bootimage?defs=COE . when you use ?defs= on the URLs, it parses the standard linuxcoe.rc first and then another file overriding any values you've redefined. We use this not only for testing but to give some internal customers a custom view. The post processing 'bootstrap' code it will append to your final script can be seen in the $PREFIX/data/*_final_skel files. These skel files are written to layer any post processing needs onto a system in 3 stages. On rpm based systems it runs a straight rpm -i @METHOD@/@WAYSTATION@/whatever.rpm kind of thing, on deb based system it will wget && dpkg -I the files. The sole intention of the first 3 stages is to configure apt/yum/up2date/etc. to point at internal waystations and to deliver the LinuxCOE bundle installer. If there you have ADDONS defined and chose custom bundles during image creation, a 4 step is called that would install this software using APT || YUM depending on distro now that it's configured to point at your waystation. If you're simply wanting to ensure your servers end up pointed at your standard mirrors, you'll only need to install the deb that configures APT on the clients to point back at you. The post processing stuff is on sf here: http://linuxcoe.cvs.sourceforge.net/viewvc/linuxcoe/postproc/ http://linuxcoe.cvs.sourceforge.net/viewvc/linuxcoe/postproc/deb/apt-config/linux-2.6-all/linuxcoe-sw-sources-4.0-linux-2.6-all.deb?revision=1.1.1.1 - oops, I accidentally checked in the .deb vs. just source for it. :^) I started using EPM to do my packaging a long time ago when I supported HPUX and Linux since I'm lazy and I only had to learn one packaging meta-language. That's the 'format' of this check-in. You can apt-get install epm, its home is http://www.epmhome.org/ . You'll want to build linuxcoe-sw.deb and export somewhere on your waystation. Then create the file $PREFIX/base/POST-DEB, here's our's for an example: hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/base> cat POST-DEB @ME...@li.../LinuxCOE/COE/3.1/packages/DEBS/linuxcoe-sw-sources-4.0.all.deb hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/base> The typical @METHOD@/@WAYSTATION@/etc. will get sub/replaced. This will be pulled in with a wget/dpkg -i. The last piece to configure tells the linuxcoe-sw-sources.deb what to replace the distro's default apt configuration with. That's done in $PREFIX/depots/, here's our Maverick example: hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/depots> cat apt-Ubuntu-Maverick # core distro deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick main restricted # additional goodies # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick universe multiverse # updates deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates main restricted # additional updates (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates universe multiverse # security deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security main restricted # additional security (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security universe multiverse # backports #deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports main restricted #deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports main restricted # additional backports (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports universe multiverse # proposed #deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed main restricted #deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed main restricted # additional proposed (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed universe multiverse hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/depots> I realize this is a lot to digest and kind of rambling but give a whirl and see what you end up with. All of the post processing leaves its logfiles at /var/log/LinuxCOE-* on the installing system. Bryan and I will be happy to help. Best Regards, Lee |
|
From: Mayes, L. <lee...@hp...> - 2010-12-14 13:45:55
|
Hi John, What you want to do is certainly do-able and is how we run our shop as well. While there is nothing proprietary about our post processing environment it's probably not our best documented feature even though we live and die by it on our internal System Designer instance. In the older days Deb/Ubuntu did the right thing automatically, whatever value you preseeded with was what ended up in sources.list but that appears to no longer be the case. The LinuxCOE post-processing environment runs in 4 stages, we call them PRE, MID, POST and the bundle installer proper. You'll need to make a couple of changes to enable it. In your $PREFIX/linuxcoe.rc file, comment out (or set to 0) the NO_COE directive. This tells the image generation scripts that you desire LinuxCOE post processing and they will append the bootstrap that calls it to your %final script. If folks are currently using your system designer instance and you want to test/debug this functionality alongside but without touching your existing deployments, create the file $PREFIX/COE containing the single line 'NO_COE 0' (without quotes) and append ?defs=COE to your URLs, for example http://your_server/systemdesigner-cgi-bin/coe_bootimage?defs=COE . when you use ?defs= on the URLs, it parses the standard linuxcoe.rc first and then another file overriding any values you've redefined. We use this not only for testing but to give some internal customers a custom view. The post processing 'bootstrap' code it will append to your final script can be seen in the $PREFIX/data/*_final_skel files. These skel files are written to layer any post processing needs onto a system in 3 stages. On rpm based systems it runs a straight rpm -i @METHOD@/@WAYSTATION@/whatever.rpm kind of thing, on deb based system it will wget && dpkg -I the files. The sole intention of the first 3 stages is to configure apt/yum/up2date/etc. to point at internal waystations and to deliver the LinuxCOE bundle installer. If there you have ADDONS defined and chose custom bundles during image creation, a 4 step is called that would install this software using APT || YUM depending on distro now that it's configured to point at your waystation. If you're simply wanting to ensure your servers end up pointed at your standard mirrors, you'll only need to install the deb that configures APT on the clients to point back at you. The post processing stuff is on sf here: http://linuxcoe.cvs.sourceforge.net/viewvc/linuxcoe/postproc/ http://linuxcoe.cvs.sourceforge.net/viewvc/linuxcoe/postproc/deb/apt-config/linux-2.6-all/linuxcoe-sw-sources-4.0-linux-2.6-all.deb?revision=1.1.1.1 - oops, I accidentally checked in the .deb vs. just source for it. :^) I started using EPM to do my packaging a long time ago when I supported HPUX and Linux since I'm lazy and I only had to learn one packaging meta-language. That's the 'format' of this check-in. You can apt-get install epm, its home is http://www.epmhome.org/ . You'll want to build linuxcoe-sw.deb and export somewhere on your waystation. Then create the file $PREFIX/base/POST-DEB, here's our's for an example: hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/base> cat POST-DEB @ME...@li.../LinuxCOE/COE/3.1/packages/DEBS/linuxcoe-sw-sources-4.0.all.deb hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/base> The typical @METHOD@/@WAYSTATION@/etc. will get sub/replaced. This will be pulled in with a wget/dpkg -i. The last piece to configure tells the linuxcoe-sw-sources.deb what to replace the distro's default apt configuration with. That's done in $PREFIX/depots/, here's our Maverick example: hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/depots> cat apt-Ubuntu-Maverick # core distro deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick main restricted # additional goodies # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick universe multiverse # updates deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates main restricted # additional updates (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-updates universe multiverse # security deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security main restricted deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security main restricted # additional security (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-security universe multiverse # backports #deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports main restricted #deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports main restricted # additional backports (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-backports universe multiverse # proposed #deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed main restricted #deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed main restricted # additional proposed (should enable these if doing the corresponding ones above) # deb @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed universe multiverse # deb-src @METHOD@@WAYSTATION@/LinuxCOE/Ubuntu maverick-proposed universe multiverse hpcoe@g2t0002:/usr/local/linuxcoe-sd/4.2/etc/depots> I realize this is a lot to digest and kind of rambling but give a whirl and see what you end up with. All of the post processing leaves its logfiles at /var/log/LinuxCOE-* on the installing system. Bryan and I will be happy to help. Best Regards, Lee -----Original Message----- From: Cusick, John CTR NAWCWD, 541400D [mailto:joh...@na...] Sent: Monday, December 13, 2010 6:58 PM To: Mayes, Lee; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors Lee and Bryan, Actually, what I'm trying to do is have the systems install from my waystation and not access the Ubuntu (or Debian) public mirrors at all... ever. Management wants a single point of installation and updates with control over what gets installed and updated, particularly the kernel. They are lenient on choice of distributions, however, which is why I chose LinuxCOE as a starting point. That and the web-based installation disk creation which is perfect in an environment where only 1 of the Sys Admins is technically responsible for all the Linux systems here, but all sys admins may be required to install, and secure, the Linux Desktops. Eventually (shortly) this will be required for all the rpm-based and deb-based distros we support here. I've set up two different LinuxCOE systems, one for debs and one for rpms, including appropriate mirrors (centos, fedora, ubuntu, etc., depending on user prefs/requirements), and since I'm less experienced with debian way than Redahat/Fedora/CentOS I figured I'd start with the deb system setup first since I would find it more interesting :-) Also, due to some restrictions on network access locally, some of the chosen US mirrors are blocked or tightly choked. For example, the basic desktop install I tested last week took over 2 hours across the 'net. At home the same basic install took about 45 minutes complete to the working desktop, and my ISP at home supplies a far smaller bandwidth than I have available here. Not so good when I'm trying to grab some bragging rights with the local MS Guys :-) I figured that since we must have the mirrors, the LinuxCOE system would be a perfect adjunct for non-linux-oriented sys admins to put together installations with a minimum time and knowledge requirement while also meeting our platform and security update requirements. That, and the PRE, MID and POST stuff looks very interesting for downloading locally required security packages, documentation, scripts, etc. to speed up the final hands-on portion of the installation. My perl skills are inadequate at best, although I did spend some time with the source code last week which helped, but right now I'm not really sure of the most effective way to do all this. I tested what I interpreted the answer to be (below), but as you pointed out, Lee, it isn't working as setup out of the box. (LinuxCOE 4.3, by the way - installation and basic setup from source was a breeze, and Thank You all for that). Is it possible to setup a post-processing environment outside a H-P Facility? From what I saw in the code and read in various docs online at H-P, it looks like there may be some proprietary software involved. Or do I need to rebuild the appropriate apt debian packages (assuming they are delivered as part of the waystation package) so that they point to my server mirror only? Regards, John C. -----Original Message----- From: Mayes, Lee [mailto:lee...@hp...] Sent: Monday, December 13, 2010 12:24 To: Cusick, John CTR NAWCWD, 541400D; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors The depots directory is scraped and applied only if running the full LinuxOE post-processing environment. You'll also need to set up the stuff in linuxcoe-sd/base/ stuff to reference our post processing RPM. BryanG, do we do that out of the box? John, If repointing the installed boxes to your waystation is all you need you might just sed sources.lists.d/* to populate with your values in the final script. Lee -----Original Message----- From: Cusick, John CTR NAWCWD, 541400D [mailto:joh...@na...] Sent: Monday, December 13, 2010 3:08 PM To: Gartner, Bryan W Cc: lin...@li... Subject: Re: [Linuxcoe-users] Using Mirrors Bryan, Wow! That was a very quick reply. Ah... so I think I got it! In other words, I use the linuxcoe-sd/depot directory and, for example, the apt-Ubuntu-Maverick file would have the following entries, (ubuntu-lds being the name of my server): deb @ME...@ub.../ubuntu/ maverick main multiverse restricted universe deb @ME...@ub.../ubuntu/ maverick-updates main multiverse restricted universe whereas in the linuxcoe-sd/osvend.d the Ubuntu file has the following entry: OSVEND ubuntu-lds.my.domain.mil Ubuntu Maverick x86_64 HTTP /ubuntu/ At image creation time, in my case using http, @METHOD@ will be translated to http, Correct? I'm a little new to mirroring debian-based distros and I've not always been sure of the correct syntax, although I am now making the assumption that it should match the standard sources.list file (not to mention that I'm not really strong with perl, either :-). That may have been where my initial tests had failed to do what I expected as the linuxcoe-sd/depot/ files were not 'right' compared to a typical sources.list file. Thanks again. Regards, John Cusick -----Original Message----- From: Bryan Gartner [mailto:bry...@hp...] Sent: Monday, December 13, 2010 11:34 To: Cusick, John CTR NAWCWD, 541400D Cc: lin...@li... Subject: Re: [Linuxcoe-users] Using Mirrors John, On Mon, Dec 13, 2010 at 06:55:05PM +0000, Cusick, John CTR NAWCWD, 541400D wrote: > I've setup LinuxCoe locally and first tests have been basically successful. Good deal, feel free to follow-up with other questions you may have. > I do have one question regarding waystations, however. > > I was under the impression that the entire workstation would be loaded from the server entered as the OSVEND, but that does not seem to be the case. Although the install starts from there, the packages are downloaded from outside-the-local-network mirrors instead of the locally setup mirror. Actually, think of OSVEND as a simple point mechanism to any valid distribution mirror. > Is there a way from within LinuxCOE to force the local mirror as the only download point? Specifically, I have an Ubuntu waystation/mirror setup and although it correctly used the waystation/mirror during the initial load phase, once the software install started it accessed us.archive.ubuntu.com. I would like it to use the local mirror only. You can augment/replace any tuple (distro/version/arch) combination with as many mirrors as you'd like, whether remote or local to your environment. Simply follow the syntax examples in the file of interest. > In case this is not the best place to ask questions, is there a better list or forum to use? This is entirely fine, ask away :) bryang |
|
From: Cusick, J. C. N. 5. <joh...@na...> - 2010-12-13 23:58:51
|
Lee and Bryan, Actually, what I'm trying to do is have the systems install from my waystation and not access the Ubuntu (or Debian) public mirrors at all... ever. Management wants a single point of installation and updates with control over what gets installed and updated, particularly the kernel. They are lenient on choice of distributions, however, which is why I chose LinuxCOE as a starting point. That and the web-based installation disk creation which is perfect in an environment where only 1 of the Sys Admins is technically responsible for all the Linux systems here, but all sys admins may be required to install, and secure, the Linux Desktops. Eventually (shortly) this will be required for all the rpm-based and deb-based distros we support here. I've set up two different LinuxCOE systems, one for debs and one for rpms, including appropriate mirrors (centos, fedora, ubuntu, etc., depending on user prefs/requirements), and since I'm less experienced with debian way than Redahat/Fedora/CentOS I figured I'd start with the deb system setup first since I would find it more interesting :-) Also, due to some restrictions on network access locally, some of the chosen US mirrors are blocked or tightly choked. For example, the basic desktop install I tested last week took over 2 hours across the 'net. At home the same basic install took about 45 minutes complete to the working desktop, and my ISP at home supplies a far smaller bandwidth than I have available here. Not so good when I'm trying to grab some bragging rights with the local MS Guys :-) I figured that since we must have the mirrors, the LinuxCOE system would be a perfect adjunct for non-linux-oriented sys admins to put together installations with a minimum time and knowledge requirement while also meeting our platform and security update requirements. That, and the PRE, MID and POST stuff looks very interesting for downloading locally required security packages, documentation, scripts, etc. to speed up the final hands-on portion of the installation. My perl skills are inadequate at best, although I did spend some time with the source code last week which helped, but right now I'm not really sure of the most effective way to do all this. I tested what I interpreted the answer to be (below), but as you pointed out, Lee, it isn't working as setup out of the box. (LinuxCOE 4.3, by the way - installation and basic setup from source was a breeze, and Thank You all for that). Is it possible to setup a post-processing environment outside a H-P Facility? From what I saw in the code and read in various docs online at H-P, it looks like there may be some proprietary software involved. Or do I need to rebuild the appropriate apt debian packages (assuming they are delivered as part of the waystation package) so that they point to my server mirror only? Regards, John C. -----Original Message----- From: Mayes, Lee [mailto:lee...@hp...] Sent: Monday, December 13, 2010 12:24 To: Cusick, John CTR NAWCWD, 541400D; Gartner, Bryan W Cc: lin...@li... Subject: RE: [Linuxcoe-users] Using Mirrors The depots directory is scraped and applied only if running the full LinuxOE post-processing environment. You'll also need to set up the stuff in linuxcoe-sd/base/ stuff to reference our post processing RPM. BryanG, do we do that out of the box? John, If repointing the installed boxes to your waystation is all you need you might just sed sources.lists.d/* to populate with your values in the final script. Lee -----Original Message----- From: Cusick, John CTR NAWCWD, 541400D [mailto:joh...@na...] Sent: Monday, December 13, 2010 3:08 PM To: Gartner, Bryan W Cc: lin...@li... Subject: Re: [Linuxcoe-users] Using Mirrors Bryan, Wow! That was a very quick reply. Ah... so I think I got it! In other words, I use the linuxcoe-sd/depot directory and, for example, the apt-Ubuntu-Maverick file would have the following entries, (ubuntu-lds being the name of my server): deb @ME...@ub.../ubuntu/ maverick main multiverse restricted universe deb @ME...@ub.../ubuntu/ maverick-updates main multiverse restricted universe whereas in the linuxcoe-sd/osvend.d the Ubuntu file has the following entry: OSVEND ubuntu-lds.my.domain.mil Ubuntu Maverick x86_64 HTTP /ubuntu/ At image creation time, in my case using http, @METHOD@ will be translated to http, Correct? I'm a little new to mirroring debian-based distros and I've not always been sure of the correct syntax, although I am now making the assumption that it should match the standard sources.list file (not to mention that I'm not really strong with perl, either :-). That may have been where my initial tests had failed to do what I expected as the linuxcoe-sd/depot/ files were not 'right' compared to a typical sources.list file. Thanks again. Regards, John Cusick -----Original Message----- From: Bryan Gartner [mailto:bry...@hp...] Sent: Monday, December 13, 2010 11:34 To: Cusick, John CTR NAWCWD, 541400D Cc: lin...@li... Subject: Re: [Linuxcoe-users] Using Mirrors John, On Mon, Dec 13, 2010 at 06:55:05PM +0000, Cusick, John CTR NAWCWD, 541400D wrote: > I've setup LinuxCoe locally and first tests have been basically successful. Good deal, feel free to follow-up with other questions you may have. > I do have one question regarding waystations, however. > > I was under the impression that the entire workstation would be loaded from the server entered as the OSVEND, but that does not seem to be the case. Although the install starts from there, the packages are downloaded from outside-the-local-network mirrors instead of the locally setup mirror. Actually, think of OSVEND as a simple point mechanism to any valid distribution mirror. > Is there a way from within LinuxCOE to force the local mirror as the only download point? Specifically, I have an Ubuntu waystation/mirror setup and although it correctly used the waystation/mirror during the initial load phase, once the software install started it accessed us.archive.ubuntu.com. I would like it to use the local mirror only. You can augment/replace any tuple (distro/version/arch) combination with as many mirrors as you'd like, whether remote or local to your environment. Simply follow the syntax examples in the file of interest. > In case this is not the best place to ask questions, is there a better list or forum to use? This is entirely fine, ask away :) bryang |
|
From: Mayes, L. <lee...@hp...> - 2010-12-13 20:25:15
|
The depots directory is scraped and applied only if running the full LinuxOE post-processing environment. You'll also need to set up the stuff in linuxcoe-sd/base/ stuff to reference our post processing RPM. BryanG, do we do that out of the box? John, If repointing the installed boxes to your waystation is all you need you might just sed sources.lists.d/* to populate with your values in the final script. Lee -----Original Message----- From: Cusick, John CTR NAWCWD, 541400D [mailto:joh...@na...] Sent: Monday, December 13, 2010 3:08 PM To: Gartner, Bryan W Cc: lin...@li... Subject: Re: [Linuxcoe-users] Using Mirrors Bryan, Wow! That was a very quick reply. Ah... so I think I got it! In other words, I use the linuxcoe-sd/depot directory and, for example, the apt-Ubuntu-Maverick file would have the following entries, (ubuntu-lds being the name of my server): deb @ME...@ub.../ubuntu/ maverick main multiverse restricted universe deb @ME...@ub.../ubuntu/ maverick-updates main multiverse restricted universe whereas in the linuxcoe-sd/osvend.d the Ubuntu file has the following entry: OSVEND ubuntu-lds.my.domain.mil Ubuntu Maverick x86_64 HTTP /ubuntu/ At image creation time, in my case using http, @METHOD@ will be translated to http, Correct? I'm a little new to mirroring debian-based distros and I've not always been sure of the correct syntax, although I am now making the assumption that it should match the standard sources.list file (not to mention that I'm not really strong with perl, either :-). That may have been where my initial tests had failed to do what I expected as the linuxcoe-sd/depot/ files were not 'right' compared to a typical sources.list file. Thanks again. Regards, John Cusick -----Original Message----- From: Bryan Gartner [mailto:bry...@hp...] Sent: Monday, December 13, 2010 11:34 To: Cusick, John CTR NAWCWD, 541400D Cc: lin...@li... Subject: Re: [Linuxcoe-users] Using Mirrors John, On Mon, Dec 13, 2010 at 06:55:05PM +0000, Cusick, John CTR NAWCWD, 541400D wrote: > I've setup LinuxCoe locally and first tests have been basically successful. Good deal, feel free to follow-up with other questions you may have. > I do have one question regarding waystations, however. > > I was under the impression that the entire workstation would be loaded from the server entered as the OSVEND, but that does not seem to be the case. Although the install starts from there, the packages are downloaded from outside-the-local-network mirrors instead of the locally setup mirror. Actually, think of OSVEND as a simple point mechanism to any valid distribution mirror. > Is there a way from within LinuxCOE to force the local mirror as the only download point? Specifically, I have an Ubuntu waystation/mirror setup and although it correctly used the waystation/mirror during the initial load phase, once the software install started it accessed us.archive.ubuntu.com. I would like it to use the local mirror only. You can augment/replace any tuple (distro/version/arch) combination with as many mirrors as you'd like, whether remote or local to your environment. Simply follow the syntax examples in the file of interest. > In case this is not the best place to ask questions, is there a better list or forum to use? This is entirely fine, ask away :) bryang |
|
From: Cusick, J. C. N. 5. <joh...@na...> - 2010-12-13 20:08:16
|
Bryan, Wow! That was a very quick reply. Ah... so I think I got it! In other words, I use the linuxcoe-sd/depot directory and, for example, the apt-Ubuntu-Maverick file would have the following entries, (ubuntu-lds being the name of my server): deb @ME...@ub.../ubuntu/ maverick main multiverse restricted universe deb @ME...@ub.../ubuntu/ maverick-updates main multiverse restricted universe whereas in the linuxcoe-sd/osvend.d the Ubuntu file has the following entry: OSVEND ubuntu-lds.my.domain.mil Ubuntu Maverick x86_64 HTTP /ubuntu/ At image creation time, in my case using http, @METHOD@ will be translated to http, Correct? I'm a little new to mirroring debian-based distros and I've not always been sure of the correct syntax, although I am now making the assumption that it should match the standard sources.list file (not to mention that I'm not really strong with perl, either :-). That may have been where my initial tests had failed to do what I expected as the linuxcoe-sd/depot/ files were not 'right' compared to a typical sources.list file. Thanks again. Regards, John Cusick -----Original Message----- From: Bryan Gartner [mailto:bry...@hp...] Sent: Monday, December 13, 2010 11:34 To: Cusick, John CTR NAWCWD, 541400D Cc: lin...@li... Subject: Re: [Linuxcoe-users] Using Mirrors John, On Mon, Dec 13, 2010 at 06:55:05PM +0000, Cusick, John CTR NAWCWD, 541400D wrote: > I've setup LinuxCoe locally and first tests have been basically successful. Good deal, feel free to follow-up with other questions you may have. > I do have one question regarding waystations, however. > > I was under the impression that the entire workstation would be loaded from the server entered as the OSVEND, but that does not seem to be the case. Although the install starts from there, the packages are downloaded from outside-the-local-network mirrors instead of the locally setup mirror. Actually, think of OSVEND as a simple point mechanism to any valid distribution mirror. > Is there a way from within LinuxCOE to force the local mirror as the only download point? Specifically, I have an Ubuntu waystation/mirror setup and although it correctly used the waystation/mirror during the initial load phase, once the software install started it accessed us.archive.ubuntu.com. I would like it to use the local mirror only. You can augment/replace any tuple (distro/version/arch) combination with as many mirrors as you'd like, whether remote or local to your environment. Simply follow the syntax examples in the file of interest. > In case this is not the best place to ask questions, is there a better list or forum to use? This is entirely fine, ask away :) bryang |
|
From: Bryan G. <bry...@hp...> - 2010-12-13 19:47:12
|
John, On Mon, Dec 13, 2010 at 06:55:05PM +0000, Cusick, John CTR NAWCWD, 541400D wrote: > I've setup LinuxCoe locally and first tests have been basically successful. Good deal, feel free to follow-up with other questions you may have. > I do have one question regarding waystations, however. > > I was under the impression that the entire workstation would be loaded from the server entered as the OSVEND, but that does not seem to be the case. Although the install starts from there, the packages are downloaded from outside-the-local-network mirrors instead of the locally setup mirror. Actually, think of OSVEND as a simple point mechanism to any valid distribution mirror. > Is there a way from within LinuxCOE to force the local mirror as the only download point? Specifically, I have an Ubuntu waystation/mirror setup and although it correctly used the waystation/mirror during the initial load phase, once the software install started it accessed us.archive.ubuntu.com. I would like it to use the local mirror only. You can augment/replace any tuple (distro/version/arch) combination with as many mirrors as you'd like, whether remote or local to your environment. Simply follow the syntax examples in the file of interest. > In case this is not the best place to ask questions, is there a better list or forum to use? This is entirely fine, ask away :) bryang |
|
From: Cusick, J. C. N. 5. <joh...@na...> - 2010-12-13 19:16:18
|
To All, I've setup LinuxCoe locally and first tests have been basically successful. I do have one question regarding waystations, however. I was under the impression that the entire workstation would be loaded from the server entered as the OSVEND, but that does not seem to be the case. Although the install starts from there, the packages are downloaded from outside-the-local-network mirrors instead of the locally setup mirror. Is there a way from within LinuxCOE to force the local mirror as the only download point? Specifically, I have an Ubuntu waystation/mirror setup and although it correctly used the waystation/mirror during the initial load phase, once the software install started it accessed us.archive.ubuntu.com. I would like it to use the local mirror only. In case this is not the best place to ask questions, is there a better list or forum to use? Thanks John C |
