Re: Change SAMBA password
No, it has to do with replicating LDAP. We would like to connect to the central registration but first of all there is a limit to that connections and replicating to a local LDAP would mean a 24 hour delay in replicating userid's and passwords. So it's more a technical reason. Barry; We have SAMBA authenticating Windows clients directly into AD, using winbind. Linux then participates in the AD just as if it were any other arbitrary Windows server. There is no LDAP replication involved. There are some ugly hairs (especially if you have a very large AD) but overall it works quite well. Have you considered doing this, and avoiding the need to sync passwords entirely? ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Install of SLES 11 via FTP...
Your problem is that all the file names are in upper-case (or perhaps that the FTP server is reporting them that way). I ran into a slightly different example of this problem using a Windows FTP client to transfer the files from a physical SLES 10 DVD in my desktop to a Linux FTP server, which I then attempted to install from. The Windows FTP client smashed the case of the filenames to all-lower and the YaST installer failed once it started looking for RPM packages. A different, case-preserving Windows FTP client was engaged, and the installer magically began working again. ok r. -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Frank M. Ramaekers Sent: Wednesday, January 06, 2010 1:44 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Install of SLES 11 via FTP... Yeah, I did try /pub/outgoing/Suse as well (just didn't show it in the post). Frank M. Ramaekers Jr. Systems Programmer MCP, MCP+I, MCSE RHCE American Income Life Insurance Co. Phone: (254)761-6649 1200 Wooded Acres Dr.Fax: (254)741-5777 Waco, Texas 76710 -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Dave Jones Sent: Wednesday, January 06, 2010 3:38 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Install of SLES 11 via FTP... That's exactly what you want to specify to the install scriptthe path to the root of the DVD, i.e., the mount point of the DVD. On 01/06/2010 03:37 PM, Frank M. Ramaekers wrote: H...I could try that, but I tried to stay with the way the DVDs are layed out (/pub/outgoing/Suse being equivalent to the root of the DVDs). Frank M. Ramaekers Jr. Systems Programmer MCP, MCP+I, MCSE RHCE American Income Life Insurance Co. Phone: (254)761-6649 1200 Wooded Acres Dr.Fax: (254)741-5777 Waco, Texas 76710 -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Scott Rohling Sent: Wednesday, January 06, 2010 3:30 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Install of SLES 11 via FTP... I'm thinking you don't want that extra 'SUSE' -- just /pub/outgoing/Suse for the directory on the server... ? Scott On Wed, Jan 6, 2010 at 2:19 PM, Frank M. Ramaekersframaek...@ailife.comwrote: I'm having installing SLES 11 via FTP into a virtual machine. I get to the point where I'm receiving: *** No repository found. I'm thinking that it's my directory structure on the FTP server. I entered the following: Enter the IP address of the FTP server Ý10.2.0.99¨ Enter the directory on the server Ý/pub/outgoing/Suse/SUSE¨ Do you need a username and password to access the FTP server? 1) Yes 2) No 2 Use a HTTP proxy? 1) Yes 2) No 2 *** No repository found. - Here's how I have it structured: 230 Anonymous user logged in ftp pwd 257 / is your current location ftp cd pub 250 OK. Current directory is /pub ftp cd outgoing 250 OK. Current directory is /pub/outgoing ftp cd Suse 250 OK. Current directory is /pub/outgoing/Suse ftp ls 200 PORT command successful 150 Connecting to port 5001 . .. ARCHIVES.GZ BOOT CHANGELO CONTENT CONTENT.ASC CONTENT.KEY CONTROL.XML COPYING COPYING.DE COPYRIGH COPYRIGH.DE DIRECTOR.YAS DOCU GPG_P000.ASC GPG_P001.ASC GPG_P002.ASC GPG_P003.ASC GPG_P004.ASC GPG_P005.ASC GPG_PUBK.ASC INDEX.GZ LICENSE.TGZ LS_LR.GZ MEDIA.1 NEWS PUBRING.GPG README SUSE SUSE.INS 226-Options: -a 226 31 matches total ftp: 331 bytes received in 0.02Seconds 20.69Kbytes/sec. ftp TIA, Frank M. Ramaekers Jr. Systems Programmer MCP, MCP+I, MCSE RHCE American Income Life Insurance Co. Phone: (254)761-6649 1200 Wooded Acres Dr.Fax: (254)741-5777 Waco, Texas 76710 _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com. - - For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to
dasd_mod probe behavior change on SLES11?
I am preparing to begin deployment of SLES11. One issue I am having relates to the assignment of device minor numbers in the dasd_mod driver. In previous releases we could specify dasd=292-2FF in the zipl config, to achieve a static mapping of MDISK addresses to /dev/dasd* names. i.e. 2a9 would always be dasdx. In SLES11 this no longer seems to work. Even worse, it doesn't even guarantee ordering anymore. i.e. I had 293=dasdb and 2a9=dasdc, right up until I did a mkinitrd. Now I have 2a9=dasdb and 293=dasdc, which makes my fstab accurate only until the next time mkinitrd reorders everything. I read about somebody else having a different problem with dasd device mapping on SLES11, and the answer to her question was to mess with the dasd files in /etc/udev/conf.d. I took a look in there and did not find anything obviously relevant to my problem. Perhaps I did not look carefully enough. Ideas? ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: dasd_mod probe behavior change on SLES11?
That would work. I guess I'm also looking for information why this behavior deviates from what's published in the IBM Device Drivers, Features and Commands doc (Setting up the DASD device driver). ok r. -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Mark Post Sent: Monday, November 23, 2009 1:39 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: dasd_mod probe behavior change on SLES11? On 11/23/2009 at 3:59 PM, Stricklin, Raymond J raymond.j.strick...@boeing.com wrote: -snip- Ideas? When doing the install, use the persistent names (by-path) that get created. It should be the default in SLES11. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: dasd_mod probe behavior change on SLES11?
-Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Mark Post Subject: Re: dasd_mod probe behavior change on SLES11? On 11/23/2009 at 5:56 PM, Stricklin, Raymond J raymond.j.strick...@boeing.com wrote: That would work. I guess I'm also looking for information why this behavior deviates from what's published in the IBM Device Drivers, Features and Commands doc (Setting up the DASD device driver). Because with SLES11, udev is the one making the decisions for device names, not any particular device driver. What's in /etc/udev/rules.d/51-dasd-*.rules determines names for DASD devices. Mark; As near as I can tell, that's only true for device names in /dev/disk. udev keys off the kernel name (dasd...) to make symbolic links in /dev/disk which point back to /dev/dasd*. It has no effect on the /dev/dasd* names which are exposed directly from the kernel to devfs, based on the minor numbers assigned by the driver... which, speaking of: The IBM doc specifically describes how the driver allocates device minor numbers, which is inconsistent with the observed behavior in SLES11. vm-ldap-1:/etc # cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (s390x) VERSION = 11 PATCHLEVEL = 0 vm-ldap-1:/etc # strings /proc/kcore | grep dasd= root=/dev/dasda1 TERM=dumb elevator=cfq dasd=292-2FF,fixedbuffers vmpoff=LOGOFF vm-ldap-1:/etc # lsdasd Bus-ID Status Name Device Type BlkSz Size Blocks == 0.0.0292 active dasda 94:0ECKD 4096 3521MB901440 0.0.02a9 active dasdb 94:4ECKD 4096 3521MB901440 0.0.0293 active dasdc 94:8FBA 512244MB 50 vm-ldap-1:/etc # ls -l /dev/dasd? brw-rw 1 root disk 94, 0 Nov 23 11:17 /dev/dasda brw-rw 1 root disk 94, 4 Nov 23 11:17 /dev/dasdb brw-rw 1 root disk 94, 8 Nov 23 11:17 /dev/dasdc With the dasd= option set as shown, 293 should have minor number 4 (and thus be dasdb), and 2a9 should have minor number 92 (and be dasdx). Always. At least, according to the way I understand the Drivers doc. That said, I suppose from a practical standpoint my problem is solved by using /dev/disk/by-path. From a pedagogical standpoint, it's annoying for this kind of thing to change without any (obvious) documentation. I feel the same way about the dropping of hcp in favor of vmcp. Practically speaking, it's the same thing. But my coworkers, following documentation written for installing SLES10, would not necessarily have been able to get from hcp is missing to use vmcp instead with the release notes making no mention of it. There have been other surprises in SLES11. Not all of them hang on Novell. This is some of the hidden cost involved in the infinite monkeys theorem as practiced by open source development. (I am rambling now.) ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: time oddity - maybe a z/VM question
'date' reports the current time and date, along with the current time zone. Does 'date' show MST? Or is it CST, but an hour off? In the case of the former: You can set the timezone in Linux (UNIX) on a per-user basis. It's the TZ environment variable. You may have it set for your user session. echo $TZ If it's blank, you're getting the system default (what appears in YaST), and I can't account for the difference. If it's set to MST7MDT or whatever, then you have your answer. The next trick is to figure out where it's being (re)set from. Worst case, you can unset TZ for Websphere to pick up the default, or set it outright to CST6CDT. If the time zone is correct but the clock is off, something else is wrong. ok r. -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of bruce.light...@its.ms.gov Sent: Wednesday, November 18, 2009 2:56 PM To: LINUX-390@VM.MARIST.EDU Subject: time oddity - maybe a z/VM question can some one point me toward the setting I need to twiddle for getting the time on a linux guest to match the time on the z/VM ? hardware clock is set to UTC, z/VM shows the correct time for this time zone ( U.S. Central Standard ), yast has the correct settings, linux guest is 1 hour slow - even though yast shows Central time, the time being shown is Mountain time. wouldn't really bother me but the WebSphere processes expect to be pretty closely in sync with the z/OS world that they are talking to Thanks, Bruce -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DHCP
-Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Thang Pham Subject: DHCP I am trying to install a DHCP server on my SLES10 SP2 system on s390x. I think the installation worked, but I want to know how to configure new Linux systems to use DHCP. What does your network look like? Layer 2 VSWITCH? Layer 3? It probably makes a difference. One thing I found with the DHCP server when we moved from SLES9 to SLES10, I specifically had to add 'always-broadcast on' to dhcpd.conf before any of the clients would work. It's possible this was due to our layer 3 VSWITCH. We have since moved to layer 2 and I have not done any testing to remove the option, yet. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: running NTP with Linux under z/VM
Thanks, Rob. This is the kind of information I was looking for. Rich, I thought there might be performance (dispatch) issues, so your advice was also helpful. I think I'm going to stick with allowing customers to periodically re-synchronize with the UNIX time service on an ad-hoc basis using 'ntpd -q'. ok r. -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Rob van der Heij Subject: Re: running NTP with Linux under z/VM one day when virtualization gets deployed more on other platforms, they will also find the NTP algorithms don't play well with virtualization. NTP was designed to compensate for typical characteristics of network delays when you exchange time stamps with remote systems. The dispatching delays in z/VM don't behave like a network. I measured and demonstrated this causes your ntpd time to wobble much more than the plain System z TOD clock does. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: zLinux and Tapes
-Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Melancon, Ruddy Subject: zLinux and Tapes The tape we are looking at is the TS7700 VTS. This will work fine for zOS but what about zVM and zLinux. How do I use this solution to backup and restore zVM and zLinux systems for disaster recovery? Ruddy; We use the Linux TSM client to perform file-level backups of our virtual Linux machines to a zOS TSM server, so that much at least definitely works. I can't answer to the hardware supporting the zOS side. There is definitely a VTS, but I don't know if the Linux clients are using it. The other half of our backup strategy, though, is to use the STK 9840 drives attached to our zVM systems, with CA's HIDRO. This gives us image-level backups which we use for disaster recovery. I realize this doesn't quite answer your question, but it might give you some additional data you can use. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Dynamicallhy Changing Linux Guest Network
-Original Message- From: Said, Nick [mailto:nick_s...@medco.com] Sent: Sunday, August 23, 2009 7:14 AM The script reads a shared CMS file using the cmsfs package then updates config files accordingly. The input file contains network configuration items for both home and DR. By externalizing the data on a CMS disk customization of each Linux server is not required - one script fits all. We plan to use the script for initial builds at home as well. We do it in conjunction with a DHCP lease. Whenever the DHCP client receives any new configuration information, it reconfigures itself through the use of a dhcpcd-hook type script similar to what's done for SAMBA and DHCP in the default SLES release. It works for both provisioning and for DR. I can share details offlist with interested parties, as well. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: LCS problem Installing SLES 11 in partition ( more)
Heck, and I've done it with 256 MB, although the installer runs very slowly when processing package lists. 384 MB was enough to solve that problem. ok r. -Original Message- From: Mark Post [mailto:mp...@novell.com] Sent: Wednesday, June 17, 2009 12:07 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: LCS problem Installing SLES 11 in partition ( more) On 6/17/2009 at 2:30 PM, Tom Duerbusch duerbus...@stlouiscity.com wrote: How big is the guest machine size? On SLES10, I need 768 MB to load the ram disk with an OSA connection. I've never needed more that 512MB, even doing VNC installations, and that's also true for SLES11. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
XFS on SLES11
I haven't seen any documentation which states (or even suggests) that XFS is deprecated in SLES11, but it is apparently no longer a choice in YAST2 during installation. I decided to switch to XFS several years ago after many headaches with ext3's... shall we say, less enterprise-friendly features, have been extremely satisfied, and have no desire to go back at this point. Where did the option go? ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: XFS on SLES11
On 4/7/2009 at 5:28 PM, Stricklin, Raymond J wrote: I haven't seen any documentation which states (or even suggests) that XFS is deprecated in SLES11, but it is apparently no longer a choice in YAST2 during installation. That would be a bug. That's reassuring, thanks. Is there any way to work around it from the installation image, and get an XFS filesystem to install onto? If not I guess I could prep the disk on a running SLES10 system. Being able to do it from the installation image would certainly simplify my process documentation. (@; ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Two Different YaST2 Control Center displays
-Original Message- From: Mrohs, Ray [mailto:[EMAIL PROTECTED] No. They still look different. System A shows all the elements on a scrolling screen. System B shows just the elements for the active category. System A gets these messages: # yast2 lnxm500:~ # ALSA lib confmisc.c:672:(snd_func_card_driver) cannot find card '0' On systems A and B, what is the difference in output from these two commands, if any? echo $TERM chkconfig alsasound ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Striped LVM max size
Lee; With a simple stripe, there is no overhead. Striping with parity (involved in, for example, RAID-5) is where you will see overhead, as the parity bits must be stored in addition to the data. I think what you are noticing is related to the fact that you can't evenly divide 45 by 8. By selecting 8 stripes, you were only getting 40 mod 9s in your LV. 306/45 is within a reasonable error margin of 275/40. I'm willing to bet that after creating the 275 GB, 8-stripe LV, you would've had 31 GB left over in your volume group, on which you could have created a second LV (with either 1 stripe or 5 stripes). ok r. -Original Message- From: Lee Stewart [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2008 5:26 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Striped LVM max size I follow that logic. Since you can't choose 9 (in the SLES10 drop down), 5 works. Fewer than the as many stripes as you have volumes recommendation... But it still leaves my basic question -- how do you know or plan for what the max size you can use is? When we first set it up 45 mod 9s, 306GB, with 8 stripes we had to hunt and peck all the way down to 275GB...So 31GB went into the stripes. If I wanted a 300GB LVM, how do I know how much raw space I need? Thanks, Lee Mark Perry wrote: Lee Stewart wrote: SNIP For example, doing an LVM with 45 mod 9s. Round numbers math gives me 6.8GB/volume x 45 volumes = 306GB. That's close to what Max gives. But what's the number with 8 stripes? Hello Lee, The idea is to put each of the specified stripes on a different DASD. I have always used a number of stripes that was a factor of the number of DASD in the VG. So for your example of 45 DASD that would mean using a number of stripes of either 9 or 5. Also I have always added extra DASD to the VG pool in multiples of the number of stripes, in the above example that would mean adding either 9 or 5 DASD at a time. If you do not do as I suggest, then you can end up with more stripes on one or more DASD than on others. This would defeat the purpose of using stripes, which is to spread the I/O load evenly across multiple DASD. If you want to use a number of stripes of 8, then either put 48 DASD in your VG pool or reduce to 40. 48 has more factors, so with 48 DASD in the VG you could choose a number of stripes from 2,3,4,6,8,12,16,24. mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- Lee Stewart, Senior SE Sirius Computer Solutions Phone: (303) 798-2954 Fax: (720) 228-2321 Email: [EMAIL PROTECTED] Web: www.siriuscom.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Layer 2 on the VSWITCH --Take 3
From: Mark Post [mailto:[EMAIL PROTECTED] On 8/18/2008 at 11:17 AM, Alan Altmark [EMAIL PROTECTED] wrote: -snip- The OSA-Express Customer Guide and Reference says this about Layer 2 support on p.13: Hardware requirements - z890 or z990 and above only Would Layer 3 and the fake_ll headers option be a viable workaround for this? It was, in our shop. We had a z800 and no possibility for a layer 2 VSWITCH, but successfully deployed DHCP on a layer 3 VSWITCH instead, using the DHCP server in SLES10. I have to make a disclaimer on this, in that it worked for our particular setup and may not for any other arbitrary setup. It did take us a few rounds of PTFs to get it working smoothly; there are (were) lots of boundary cases between Linux and CP and the OSAs that would be called into play, giving peculiar results. That said, it's been stable and productive for about a year, and has survived the migrations both to SLES10 SP2 and to z/VM 5.3 without further incident. One of the related modifications that helped us be successful was to have the DHCP client pass the VM user name (VM00 Name from /proc/sysinfo) instead of a MAC address, and have the DHCP server assign leases based on that, instead. The fake_ll was still necessary. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Running DHCP Server on a Linux guest
Something we ran into with SLES10 SP1: # this option is REQUIRED as of SLES10 SP1 # the DHCP server will unicast DHCP ACKs without it. always-broadcast on; This must be in dhcpd.conf on the server, or the linux clients will never receive their leases. It's possible this problem does not exist if you are using a layer two (ETHERNET) VSWITCH. ok r. -Original Message- From: Ryan McCain [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2008 2:24 PM To: LINUX-390@VM.MARIST.EDU Subject: Running DHCP Server on a Linux guest We've had a heck of a time trying to get DHCPD running on SLES10. I've noticed that The Linux guest isn't accepting broadcasts. When typing tcpdump -nepi eth0 broadcast on regular x86 servers, it spits out all kinds of stuff. On the servers we have running on z/VM, nothing comes back. Can someone point me to a document that explains what needs to be configured in order to run a DHCP server? Thanks.. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Problem with sendmail (and mailx)
You should've received a DSN message in the mailbox of the user who tried to send (root) from ds019, or (less likely) in the mailbox of the Postmaster user (on most linux systems, this is equivalent to root anyway). The actual error you're getting will be in that message, and will be much more valuable for troubleshooting this error than the entry in maillog. My first guess is that your relay server (10.159.4.16) is not configured to allow relaying from any of your servers but the two that are work. If it is also using sendmail, the file defining this is usually /etc/mail/relay-domains. The DSN message (in the user's mailbox) should tell you in more certain terms, though. ok r. -Original Message- From: CHAPLIN, JAMES (CTR) [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2008 2:02 PM To: LINUX-390@VM.MARIST.EDU Subject: Problem with sendmail (and mailx) We have several RHEL 4.5 servers running Oracle. Each is a clone of the original. However I discovered that we can only send email from two (using the mailx command). I am not an expert on sendmail, however I have looked at every configuration file I can find to see if I can locate a difference between the servers that work and the servers that do not work and have come up empty. I looked at sendmail.cf and submit.cf, and their respective *.mc files, with no differences found. In the /etc/log/maillog file I found the following between servers (working and not working): Working: Jul 31 14:58:59 zn023 sendmail[30613]: m6VIwxY2030613: [EMAIL PROTECTED], ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=32986, relay=mailhost [10.159.4.16], dsn=2.0.0, stat=Sent (Message accepted for delivery) Fail to send: Jul 31 14:48:50 zn019 sendmail[27586]: m6VImo9Z027586: [EMAIL PROTECTED], ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=32985, relay=mailhost [10.159.4.16], dsn=5.0.0, stat=Service unavailable Does anyone have any insight to this and how/where the DSN values (Delivery Status Notification) is set, where I may look to find the root of this fail to send or any suggestions. James Chaplin Systems Programmer, MVS, zVM zLinux Base Technologies, Inc (703) 921-6220 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: z/Linux cloning
I also received a few requests for information about the process we follow here. For those who wrote, I would like to let you know I'm working on compiling it into a format useful for sharing and will follow up with news once it's ready. We've had a number of activities keeping us busy lately. ok r. -Original Message- From: Evans, Kevin R [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 11:59 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: z/Linux cloning Robert, Did you get my earlier email to you specifically about my interest in this process? Thanks, Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Friday, July 18, 2008 1:09 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: z/Linux cloning We have a cloning process that is down to a single zVM command to create a new image, and we can create new images in about 8 minutes time from zVM command to being able to log into the new image. The master images occupy disk space, but are not running at any time. Since the disk copies are done from zVM via Flashcopy, the cloning process is independent of filesystem choice and works with LVM managed disks. As far as I know, we're the only ones using the process at the moment. If there's an interest, I can share it with you. -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 7/18/08 10:36 AM, Quay, Jonathan (IHG) [EMAIL PROTECTED] wrote: What's the current best practices cloning solution for z/Linux under z/VM? We've used the one found in Running z/VM to Host Linux - Installation and Customization class documentation (the CLONER and CLONEDDR virtual machines). Is there one that's newer, better or better supported? We have multiple CECs, z/Linux lpars, and both Suse and Redhat, if that makes a difference. We don't anticipate creating hundreds of clones, maybe 20 or so in the first wave. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: z/Linux cloning
Our cloning process sounds similar to yours. I have an EXEC which takes care of poking VM:Secure correctly, FLASHCOPYing the necessary MDISKs, and then updating our internal recordkeeping. One command, about two seconds, then another thirty or so to IPL (assuming DNS is updated ahead of time). It's fairly well customized to our site requirements, but the basic building blocks could be easily adapted to other sites. I also suspect now that SLES10 SP2 includes support for the VMUR driver, even though I haven't yet looked closely at the options, we'll be able to get even more fancy with our automation. I can also share details with any interested parties. Some of the drawbacks of doing it from Linux (instead of from CMS) are that FLASHCOPY needs privilege class B, and you're more likely to aggravate LVM. ok r. -Original Message- From: RPN01 [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 10:09 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: z/Linux cloning We have a cloning process that is down to a single zVM command to create a new image, and we can create new images in about 8 minutes time from zVM command to being able to log into the new image. The master images occupy disk space, but are not running at any time. Since the disk copies are done from zVM via Flashcopy, the cloning process is independent of filesystem choice and works with LVM managed disks. As far as I know, we're the only ones using the process at the moment. If there's an interest, I can share it with you. -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 7/18/08 10:36 AM, Quay, Jonathan (IHG) [EMAIL PROTECTED] wrote: What's the current best practices cloning solution for z/Linux under z/VM? We've used the one found in Running z/VM to Host Linux - Installation and Customization class documentation (the CLONER and CLONEDDR virtual machines). Is there one that's newer, better or better supported? We have multiple CECs, z/Linux lpars, and both Suse and Redhat, if that makes a difference. We don't anticipate creating hundreds of clones, maybe 20 or so in the first wave. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: z/VM Linux OS VLAN tagging
What would be the security implications of a setup like this if, for example, you were running untrusted linux guests? I guess in a broader sense, where are the security boundaries? There's a lot about VLAN operation I do not yet understand, so forgive me if this is a naive question. ok r. -Original Message- From: Alan Schilla [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 11:19 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: z/VM Linux OS VLAN tagging I'm not sure this will help you but we run multiple VLANs thru a single vswitch. We define our cisco router port to the OSA as a vlan trunk defining the default gateway for each of our zVM linux VLANs. Our vswitch is defined as VLAN unaware so all the VLAN s forward traffic up the trunk to each VLAN default address on the router. Al Schilla Systems Programmer Enterprise Technology Services Office of Enterprise Technologies phone: 651-201-1216 email: [EMAIL PROTECTED] -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Bhemidhi, Ashwin Sent: Wednesday, April 23, 2008 11:04 AM To: LINUX-390@vm.marist.edu Subject: Re: z/VM Linux OS VLAN tagging 1.a) OSA port has been defined as a trunk b) OSA has been authorized the to use both VLANs on the trunk port c) trunk protocol set to dot1q 2. define vswitch vswitche rdev 3600 ethernet vlan 1000 porttype trunk 3. cp set vswitch vswitche grant svml09 porttype trunk vlan 106 730 4. vconfig add eth1 106 vconfig add eth1 730 VLAN 106 is Ethernet frame with no IP (LLC over Ethernet) VLAN 730 is IP. Our problem is when the tagging is done by the Linux guest. There is some wrong with the VLAN 106 frames going out to a Cisco router. The router for some reason is rejecting those frames. This works when we setup 2 different Vswitches using the same OSA trunk port. In this case each vswitch assigns a network interface to the Linux guest machine as an access port with default VLAN 106 and 730 respectively. Basically the vswitches in this case are doing the VLAN ID tagging and the guest sees 2 interfaces eth1 and eth2. Regards, Ashwin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Tuesday, April 22, 2008 10:38 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: z/VM Linux OS VLAN tagging On Tuesday, 04/22/2008 at 05:52 EDT, Bhemidhi, Ashwin [EMAIL PROTECTED] wrote: 1) Redhat Linux guest machine running kernel version 2.6.18-1.2747.el5 under z/VM 5.3 2) Using OSA Express 2 with Gigabit port and VLAN enabled at the network switch with 2 different VLANS. 3) The 2 VLANs are a) a VLAN for IP network for IP traffic and b) a VLAN for only Ethernet frames (LLC, no IP). 4) Configured 1 Layer 2 VSwitch with 2 VLANs and granted the Network interface as a trunk to the Linux guest machine. 1. Make sure the switch a) has the OSA port defined as a trunk b) has authorized the OSA to use both VLANs on the trunk port c) has set the trunk protocol to dot1q 2. DEFINE VSWITCH VLAN 1 (or whatever the default VLAN is for the port). By default, the default VLAN (sorry!) is the switch's native VLAN id, which defaults to 1. (extra sorry) In 5.3 you can DEFINE VSWITCH ... VLAN 2 NATIVE 1 if you want guests to have VLAN 2 by default, but keep the native (untagged)VLAN 1. 3. Make sure you grant both VLANs to the guest. Use explicit grants; don't use defaults. 4. Use vconfig to create two VLAN-specific interfaces on eth0 Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: What is a good generic disk layout?
Mark; For all you folks out there that keep wanting to put / in an LV, all I can say is masochists. I keep /boot in the root file system, and break out everything else. # df -h FilesystemSize Used Avail Use% Mounted on /dev/dasda1 388M 125M 243M 35% / /dev/mapper/vg01-home 97M 4.2M 88M 5% /home /dev/mapper/vg01-opt 74M 21M 50M 30% /opt /dev/mapper/vg01-srv 100M 33M67M 33% /srv /dev/mapper/vg01-tmp 291M 33M 244M 12% /tmp /dev/mapper/vg01-usr 1.2G 1022M 76M 94% /usr /dev/mapper/vg01-var 245M 81M 152M 35% /var This is essentially our approach, as well, although we keep things simpler. We deploy on half a 3390-9. Filesystem 1K-blocks Used Available Use% Mounted on /dev/dasda1 2393024 1372088 1020936 58% / udev 43656 100 43556 1% /dev /dev/mapper/vgroot-lvopt 801216184884616332 24% /opt /dev/mapper/vgroot-lvvar 387520 98136289384 26% /var none 43656 0 43656 0% /tmp IMO /srv is a waste of effort. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: What is a good generic disk layout?
Mark; Until some webmaster decides to dump a few 4.7GB DVD .iso files in it, and your system craters. I was speaking to its merit overall, without regard to whether to make it separate or not. I find it to be among the more sophomoric additions to the LSB in general and the FHS in particular. And in the case of the webmaster, I recommend electroshock therapy. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DASD error on zlinux ipl
chroot is designed to run a single command with a ch'd root. You can chroot a shell, which is the default, and probably what Brad was expecting to happen when he wrote his instructions. I wonder if your $SHELL is set to /sbin/loader, which would explain the error. I have no idea what /sbin/loader is, perhaps it's an initrd utility. It's not on any of my root filesystems. It's almost certainly not what you want with chroot. Something else that frequently gets missed is that chroot runs the command you specify, AFTER ch'ing the root. So, for example, if you execute chroot /mnt /sbin/zipl, what actually gets run is what WAS, before the chroot, /mnt/sbin/zipl. You probably shouldn't have been given the instructions as they were, as these become potential gotchas. I would recommend amending step 3 in Brad's instructions to chroot /mnt /sbin/sh, and then running step 4 as written. ok r. -Original Message- From: Ian S. Worthington [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2008 4:43 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: DASD error on zlinux ipl Thanks Mark. I'm not sure there is anything to mount at /usr. LGztpf mounts at /ztpf. There's a LogVol01, but I'm not sure where that's meant to mount. Certainly its not happy being mounted at /usr, which in any case already contains a whole bunch of its own stuff. In fact where ever I try to mount LogVol01 it gives the same error. -/bin/sh-3.00# mount /dev/VolGroup00/LogVol00 /mnt/sysimage2 -/bin/sh-3.00# mount /dev/VGztpf/LVztpf /mnt/sysimage2/ztpf -/bin/sh-3.00# mount /dev/VolGroup00/LogVol01 /mnt/sysimage2/usr mount: Mounting /dev/VolGroup00/LogVol01 on /mnt/sysimage2/usr failed: Device or resource busy -/bin/sh-3.00# ls /mnt/sysimage/usr X11R6 etc include lib libexec sbin src bin games kerberos lib64 local share tmp -/bin/sh-3.00# chroot /mnt/sysimage2 chroot: cannot execute /sbin/loader: No such file or directory -/bin/sh-3.00# ian ... -- Original Message -- Received: Tue, 01 Apr 2008 12:08:58 AM BST From: Mark Post [EMAIL PROTECTED] To: LINUX-390@VM.MARIST.EDU Subject: Re: DASD error on zlinux ipl On Mon, Mar 31, 2008 at 5:48 PM, in message [EMAIL PROTECTED], Ian S. Worthington [EMAIL PROTECTED] wrote: Thanks Brad. Seem to having some problems with this: -/bin/sh-3.00# chroot /mnt/sysimage2 chroot: cannot execute /sbin/loader: No such file or directory I'm using mnt/sysimage2 for this as sysimage exists: isn't that were the rescue system mounts the installation it found? I did: vgscan vgchange -a y mkdir /mnt/sysimage mount /dev/VolGroup00/LogGroup00 /mnt/sysimage2 mount /dev/dasda1 /mnt/sysimage2/boot chroot /mnt/sysimage2 I've attached the results from pvdisplay and lvdisplay. There's only one other VolGroup and that doesn't contain any boot data so I'm not worrying about mounting that just at the moment. Any thoughts? Most likely you need to mount the /usr file system as well, as Brad suggested. I would imagine /sbin/loader has shared libraries it needs to access on /usr. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: modprobe.conf
Why I am afraid of the semi-official clone method:
mounting the DASD where I copied the system and wanting to change
configuration files this way may be risky because the home
system and the mounted system both have the very same LogVol-setup.
Same setup, meaning also same names/labels.
Yet another reason not to have your root file system on a
logical volume.
LVM2 is sophisticated enough (at least for SLES10 SP1, which is our
current supported release) that having multiple objects with the same
names will cause it to fail in a predictable and easily recoverable
manner, so long as the UUIDs differ.
To that end, we employ an init script early in the boot process to
generate new pv and vg UUIDs if it detects that this is a newly-cloned
machine:
---(begin)
#! /bin/bash
#
# - post cloning housework
#
### BEGIN INIT INFO
# Provides: boot.lvmunclone
# Required-Start: boot.proc boot.udev boot.device-mapper
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start: B
# Default-Stop:
# Description:Guarantee unique LVM UUIDs on vgroot after cloning
### END INIT INFO
[ $1 != start ] exit 0
VG=vgroot
# sed, awk, and grep are all in /bin, dynamically linked with libc in
/lib64
# no need for /usr to be mounted, just for the dynamic loader to work
VM00=`awk '/VM00 Name/ { print $NF }' /proc/sysinfo`
TAGS=`vgs --noheadings -o vg_tags ${VG} | sed -e 's/,/ /g'`
case ${TAGS} in
*${VM00}*)
# VG tagged with VM00 Name, no work needed
exit 0
;;
*)
echo Regenerating LVM UUIDs (${VG}).
for dev in `pvdisplay -c | awk -F':' /:${VG}:/ { print \\$1 }`
; do
pvchange -u ${dev}
done
vgchange -u ${VG}
for tag in ${TAGS} ; do
vgchange --deltag ${tag} ${VG}
done
vgchange --addtag ${VM00} ${VG}
;;
esac
---(end)
Note that in our setup the only LVs in vgroot are for /opt and /var. /
is a non-LVM partition, and /usr is not separate (despite the comment in
the script). So far having LVs with duplicate UUIDs has not seemed to
cause any real problem---it's just PVs and VGs that really want to be
changed.
Perhaps something here will be useful to somebody.
ok
r.
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Using xfs file sys
With SLES10 SP1, 'mkfs -t xfs' fails without '-s size=4096'. This is the resulting output from 'mkfs': ---(begin) mkfs.xfs: warning - cannot set blocksize on block device /dev/dasdd1: Invalid argument Warning: the data subvolume sector size 512 is less than the sector size reported by the device (4096). meta-data=/dev/dasdd1isize=256agcount=8, agsize=75102 blks = sectsz=512 attr=0 data = bsize=4096 blocks=600816, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=4096 blocks=0, rtextents=0 mkfs.xfs: pwrite64 failed: Invalid argument mkfs.xfs: read failed: Invalid argument ---(end) A valid xfs filesystem is not written to disk, despite the output describing the resulting filesystem characteristics. Specifying '-s size=4096' results in a valid filesystem, and this output: ---(begin) meta-data=/dev/dasdd1isize=256agcount=8, agsize=75102 blks = sectsz=4096 attr=0 data = bsize=4096 blocks=600816, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=4096 sunit=1 blks realtime =none extsz=4096 blocks=0, rtextents=0 ---(end) If I attempt to create the filesystem on the non-partitioned disk device (/dev/dasdd) rather than the partitioned disk device (/dev/dasdd1), I get the same output as above (no errors), but the device is unmountable. I would second Mark Post's suggestion that a whole-disk partition be created with 'fdasd -a' and the filesystem be created on that device instead (/dev/dasdj1). ok r. -Original Message- From: Fargusson.Alan [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 10:54 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Using xfs file sys I don't think the DASD driver supports setting the sector size. Try without the -s size=4096. The device is probably formatted in 4096 byte blocks anyway. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Dott, Robert Sent: Friday, March 14, 2008 10:38 AM To: LINUX-390@VM.MARIST.EDU Subject: Using xfs file sys We are trying to evaluate XFS performance, but cannot get the mkfs to make a xfs filesys. We are sles9 sp3 and when we try to do the mkfs command get the following: mkfs -t xfs -s size=4096 /dev/dasdj mkfs.xfs: warning - cannot set blocksize on block device /dev/dasdj: Invalid argument meta-data=/dev/dasdj isize=256 agcount=8, agsize=70605 blks = sectsz=4096 data = bsize=4096 blocks=564840, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=4096 sunit=1 blks realtime =none extsz=65536 blocks=0, rtextents=0 any suggestions appreciated. thanks, bob Bob Dott AIT Technical Support Application Hosting [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] (502)-560-2908 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: preventing direct root login on the 3270 console for SLES10
I am trying to setup SLES10 to prevent direct login as root on the 3270 console for a SLES10 Linux guest. Terry; In order to do this, you need to remove or comment the entry for ttyS0 in /etc/securetty. It doesn't seem like a good idea in practice, though I couldn't put my finger on exactly why. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: preventing direct root login on the 3270 console for SLES10
Ohh, I can. If login for non-root users is broken for any reason, you're done. (Seen that happen a number of times on Intel/AMD systems.) That's precisely the sort of thing I was thinking of. The nologin situation is also a good one. I haven't worked enough with this part of Linux to have been more specific, so I chose to punt. If we were talking about, for example, Sun or pSeries, I would've been more strenuous in my recommendation. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
resizing EXT3 volumes online
We didn't have the tools in SLES9 to resize an EXT3 filesystem without unmounting it. They are finally present in SLES10, but I found this beautiful little bombshell in the manual page for ext2online: The ext2resize programs do not work on big-endian machines (Alpha, SPARC, PPC, etc). etc. would include other architectures, for example s390 and s390x. Good thing I checked the documentation before I tried to use it. Anybody want to comment? ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: resizing EXT3 volumes online
I have done it with RHEL 5 and I believe SLES 10 3-4 times and didn't encounter any problems. *shrug* YMMV. Thanks, Kyle. That was the kind of comment I was hoping to receive. I will set up a sandbox and test it out. Anyone else? ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: I am missing something basic with bash scripting.
parm_1=invalid target_system=hadley space= delim= | raw_list=$(/bin/ls /clamscan/servers) cooked_list=$(echo $raw_list | sed -e s:$space:$delim:g) echo Raw list = $raw_list echo cooked list = $cooked_list case $target_system in $cooked_list ) parm_1=valid ;; esac My $0.028 -- parm_1=invalid for system in `/bin/ls /clamscan/servers` ; do [ x$system = x$target_system ] parm_1=valid done ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: I am missing something basic with bash scripting.
I would, however, use -e instead of -f, because the system name is probably a directory, not a plain file. indeed, then why not use -d ? ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: I'm starting to tailor SLES10 with SP1.
OpenSSH will if you configure OpenSSL to use libica from IBM. Are you SURE? After I got OpenSSL using libica correctly, I spent about three months trying to make it work with OpenSSH and never got anywhere. Do you have a recipe? ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Help: Change from VTAM print to LPR PRINTING
It sounds to me like there are extra linefeeds (LFs) being introduced somewhere in the process. Printers like the dot-matrix Epson printer you are migrating away from make use of control characters to do things like advance the paper and move the print head around. One of these control characters is a linefeed (LF), which advances the paper forward one line. Another is a carriage return (CR), which moves the printhead from wherever it currently is, to the beginning of the line. During normal printing, when the end of a line is reached, both a CR and an LF are needed to prepare the printer for printing the next line. Issues like the one you are seeing arise because not all computer systems do the same thing at the end of a line. An MS-DOS or Windows system records a CR/LF combination as an end of line. A UNIX system typically uses just an LF. EBCDIC systems get around this whole issue by having a specific character for newline (NL), and of course the idea of the fixed record length file eliminates the need for an end-of-line character entirely. If you were to send just straight text from an ASCII system to a printer (ignoring any intermediary subsystem which might introduce its own carriage control commands), MS-DOS text would print correctly, as you would expect a printed document to look. UNIX text would print like this: this is the first line this is the second line this is the third line because there is no CR telling the printer to move the print head back to the beginning of the line---just a LF to advance the paper. An old-school Macintosh uses just a CR character as an end-of-line. If you were to send text formatted this way to a printer (again, ignoring any intermediary subsystems), the resulting hardcopy would have everything printed on one line, as there is no LF to advance the paper. As a way to deal with this diversity, printers like the Epson you are migrating away from have configuration settings for automatic LF after CR. Enabling this option when connecting the printer to an Apple allows text to be printed normally, as the printer automatically performs a linefeed after receiving a CR, without having to explicitly be told to do so. If you enable this option when connecting the printer to an MS-DOS PC, you get double-spaced text, because the printer performs an automatic linefeed after receiving the CR, and then performs a second LF as instructed by the PC. UNIX systems remain unaffected because the printer never receives a CR. Now. That being said this obviously has very little to do with the mechanics of laser printing, though because people expect to be able to print text files this way using laser printers, the behavior must be simulated in software on the printer. I do not know if modern laser printers still have the configuration option to enable or disable the automatic LF after CR, but this is something to look at. The simplest solution to this problem is to determine whether the two printers are configured the same in this regard, and if not, configure the laser printer the same way as the Epson dot matrix was. If the HP laser printers are not dedicated to this task (i.e. they are used for other print jobs) you may find this approach disruptive to other print jobs sent to these printers. If they are already configured the same (or may not be made so), you will need to look to other intermediary pieces of software where these LFs and CRs may be manipulated beyond what appears directly in the text file itself; for example, the UNIX printing system takes care of sending the necessary CRs to the printer, even though they do not appear in the text. The EXTRA print server you were using may have been doing something similar, or even possibly removing extra carriage control characters. If this is the case, you will need to simulate elsewhere whatever it's doing... RSCS may have some carriage control options which may be of some use in this endeavor. It's possible that there are LFs in your data which were introduced as a workaround for an issue similar to one described above... in that case they could be removed and your problem would be solved. Hopefully this information will help you figure out where to look for the answer. Good luck! ok r. -Original Message- From: Jan Canavan [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 11:31 AM To: LINUX-390@VM.MARIST.EDU Subject: Help: Change from VTAM print to LPR PRINTING I have not done this, so I can't help Sharon, has anyone else? Nothing/no one is making any difference. ARGHHH Here is the current scenerio: We have VSE, VTAM, IDMS and VTAM plus a 2216 in the VM environment on a MP3000-H50. We have a report that is printed on an EPSON dot matrix printer, that is attached to a PC that is running EXTRA Printer Server. The report is generated in VSE IDMS, sent to the PC with the EXTRA Print Server
Re: Upgrading from SLES10 GA to SP1 in 9 Easy Steps
From: Aria Bamdad [mailto:[EMAIL PROTECTED] 1-After all packages are updated to SP1, if I issue SPident, get a System is NOT up-to-date. It seems like it finds SLES10 + updates and expects SLES10 SP1 even though I am at the SP1 kernel level and the system login prompt says I am at SP1 and so does /etc/SuSE-release. Anyone else sees this problem or is it just me! It is not just you! We get the same result. In our case it's a direct result of having installed Velocity's snmpd RPM for SLES10. I'm a little unhappy about the way this particular situation played out, as we apparently need Velocity's version of net-snmp for the updated MIBs, but SuSE have made it ever so slightly difficult to remove their version of it from SLES10 as it is required by hplip (the HP LaserJet drivers). In the end I just did a force install of Velocity's RPM over SuSE's. Perhaps there may have been a less rude method. The other package which causes us to not show a supported service pack in SPident is yast2-bootfloppy. This package exists in GA and is installed by default, and SPident expects to see an updated revision... but the actual package does not appear on my SP1 media. I don't know why. I think I'm going to solve the problem, now that I've identified it, by adding it to my list of packages to remove completely. I'm not sure what to do about the Velocity net-snmp issue. It would be nice, since I know nothing whatsoever about the issues, to have received an add-on (or adjunct) package from Velocity, containing new MIBs to simply add to SuSE's net-snmp package. SPident -vvv should show you which packages are preventing it from achieving nirvana in your particular environment. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Waiting for device /dev/disk/by-id/ccw-IBM.75000000029391.070e.46-part1 to appear:
From: Mark Post [mailto:[EMAIL PROTECTED] I'm not at all sure why you guys wound up with /dev/disk/by-id values in /etc/fstab. I've done probably a hundred test installs of SLES10, and I always wind up with /dev/dasda1 and such in my fstab. The mount-by-id vs. mount-by-device is a selection during filesystem setup at install time. I also have consistently seen mount-by-device as the default over several dozen installs and have never had to change it as this is the behavior I wanted. Is it possible that mount-by-id becomes the default if you are installing to FCP disks? The ID shown in the original poster's message doesn't exactly look like a WWN, but I figure it's worth asking. We are using ECKD, here. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES10 SP1 upgrade experiences
Addendum: There were cron jobs in /etc/cron.daily which we had disabled by renaming the script files to begin with a '#' character. The upgrade to SP1 left the disabled scripts in place, but installed new versions which are identical to the old ones which were disabled. I simply removed the new versions. suse-clean_catman suse-do_mandb suse.de-backup-rc.config suse.de-check-battery Also, the SP1 upgrade seems to have blanked out the relayhost directive in /etc/postfix/main.cf. Other modifications we've made to this file appear intact, which is weird. It did NOT replace Velocity's version of net-snmp. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
SLES10 SP1 upgrade experiences
I wanted to post a summary of my experiences with the SLES10 SP1 upgrade process. Some of these experiences will be submitted as bugs to Novell; some were just things I felt others might find it useful to be aware of. Starting with a clone of our (customized) master SLES10 GA system image, I chose to apply the service pack by IPLing the SP1 DVD installation system and using YaST2 to update software packages. Notes: 1. I have a list of 150 RPM packages which have been removed from our customized master SLES10 GA system image. During the documentation of this process for the GA release I discovered that it was impossible to use YaST2 to prevent these packages from being installed to begin with; it was only possible to let YaST2 install them and then remove them with rpm -e, afterward. Of these 150 packages, the SP1 update process re-installed all but three, despite my having selected the option to only update installed packages. 2. In addition to the 147 GA packages which had been re-installed, there were 30 new packages installed with SP1 which did not correspond to ones I had removed from the GA system. A nubmer of these were new 32-bit versions of packages which existed in GA as 64-bit only---some, 32-bit versions of 64-bit packages I had removed: audit-libs-32bit gtk-sharp2-32bit libgsf-32bit libgssapi-32bit libnscd-32bit libpcap-32bit mozilla-nspr-32bit mozilla-nss-32bit openct-32bit opensc-32bit The following appeared in (were available with) GA, but had not been installed until the SP1 update: libiniparser xlockmore The following are the entirely-new packages installed with SP1: gtk-engines inst-source-utils libgdiplus libssui limal-nfs-server limal-nfs-server-perl mono-winforms pciutils-ids sles-heatbeat_en sles-preparation-zseries_en sles-startup_en sles-stor_evms_en util-linux-crypto yast2-autofs yast2-boot-server yast2-control-center-qt yast2-registration zypper 3. There was one package which was automatically removed during the SP1 update: autoyast2-utils 4. Several new services were installed and some were automatically enabled (chkconfig): dumpconfoff earlygdmon mon_fsstatd off splash on splash_earlyon suseRegisteron 5. Of the services I had disabled in GA, the SP1 update re-enabled one without telling me (chkconfig). novell-zmd 6. The SP1 update also replaced the contents of /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.a001, rendering the linux guest uncommunicative on the network. We have QETH_OPTIONS=fake_ll=1 set in this file so that DHCP works correctly on our layer 3 VSWITCH. When this file was replaced, it prevented the linux guest from receiving its DHCP lease, in turn preventing the second stage of the update from completing successfully, as YaST2 could not open the X display on my desktop PC. Since this stage of the update launches YaST2 without giving the opportunity for a console login session, we had to utilize a rescue system to make the changes (in our case, a single-user boot option in zIPL) before we could continue with the update. I hope some of you may find this information useful. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: YaST and gratuitous package installation
Well I doubt you will get an Official response here. Mark Post may provide and un-official response, but for an official response I would be using their formal procedures to submit a question/problem. Good point. I guess I mostly wanted to make sure I wasn't suffering a faulty expectation or even simply using YaST wrong before I cashed in a support call. In the end, the SP1 update process re-installed about 150 packages which I had specifically removed. Someone else was dotting his i's and asked me off-list if I'd used rpm -e with --nodeps. I did not; all the RPM dependencies were satisfied organically. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
YaST and gratuitous package installation
Can I get an official explanation from SuSE why YaST2 _constantly_ messes with my package selections? I'm going through the SP1 installation right now, and I'm watching it update about 100 packages I specifically removed from my system even though I specifically made sure the option to not install any new software was checked. Update installed packages only, I believe the checkbox says. This is not the only spectacularly irritating thing it does, but I don't want to belabor the point until I hear something official from SuSE. It's behavior which is not very enterprise, in any case. Thanks. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BaseVol/GuestVol server for SLES9
Probably. Generally accepted practice in the Unix world separates /, /usr, /var, /opt, /home, and /srv (if used) into distinct filesystems. I'm going to have to respectfully disagree. Making separate filesystems without understanding the _reasons_ for making things separate filesystems is not a long-term recipe for success. Most of the reasons are technical and related to the comparatively limited hardware capacity of UNIX systems in the '70s and '80s. Filesystems were split up so that they could fit on the disks which were available at the time, and to simplify backups in an era of ~60 MB tapes and tools no more sophisticated than 'dump'. Now disks are huge and backup tools are sophisticated enough that filesystem dumps seem hopelessly archaic. These are good things, in the big picture. The big drivers for splitting up filesystems these days are to keep users from filling up the wrong disks, and to keep things running smoothly for your operators. There's no reason to make directories which are relatively static and are not subject to being filled by users into separate filesystems. If you're running a server which won't have any users logging into it, making /home a separate filesystem is pointless. It adds to the complexity of maintaining the system without adding a commensurate benefit. If /opt isn't going to have much in it or change very often, there's not a lot of reason to split it into its own filesystem. If, as frequently happens here, nobody knows what the server will look like six months down the road, or what software will be on it, making /opt a separate logical volume---which can be grown as required---is a very good idea. If your site, like ours, isn't ruthlessly efficient at managing logfile sizes, and your operators are basically punished by getting paged whenever root hits 80% at three in the morning, and you can turn the problem into something that can be dealt with in the morning by making /var a separate filesystem, do it. I'd say that today, in general, if you don't know why you're splitting it out, don't split it out. Data, on the other hand, should almost always be separate. Especially if it's data which is not controlled by the system administrators. (i.e., /srv -- a SuSE convention which I personally find loathesome) /etc and /tmp are often also split out, but less commonly. I have never, ever, EVER seen /etc split out, or at least not as anything other than a joke. Off the top of my head I can think of at least four different varieties of UNIX which won't even boot if you do that. Don't do it, it's completely unnecessary and will complicate your life in needless ways. /tmp is a different story. I've always really liked Sun's approach of making it a transient, memory-backed filesystem. It seems that on a hypervisor system like VM, where we are using VDISK for swap, there is merit in doing the same with tmpfs on linux. We're about to give it a shot and see how it works in practice. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
RSCS on 5.3
Can somebody on the list help me understand IBM's position that RSCS is becoming a $20k extra cost licensed program at z/VM 5.3? ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: RSCS on 5.3
Sorry, guys. I realized I probably should not be talking about it in as specific terms on a public mailing list. I've calmed down and spoken to our salesguy; the change is not nearly as egregious as it seemed. Our management is still going to fuss and holler about it, but I don't feel like we're being gouged anymore. If it helps, I totally misheard the pricing and what I wrote below isn't even close to being accurate. (@; ok r. _ From: Stricklin, Raymond J Sent: Friday, June 15, 2007 2:33 PM To: 'Linux on 390 Port' Subject: RSCS on 5.3 Can somebody on the list help me understand IBM's position that RSCS is becoming a $20k extra cost licensed program at z/VM 5.3? ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
SLES10, net-snmp, and Velocity
SLES10 comes with its own version of net-snmp (5.3.0). Velocity seems to provide a version of net-snmp for SLES10 (5.2.2). SuSE has made it microscopically difficult to remove their net-snmp by placing upon it a dependency from hplip. I would like to make it clear that this is a dependency I do not care about in the least. However, I do want to dot all my i's. So. In the search for a more perfect enlightenment, thus: is there any particular reason why we should not (or would not want to) use SuSE's net-snmp with Velocity? Are there customizations present in Velocity's RPM which we would need? Are there support requirements from Velocity's perspective, to use their net-snmp package? Thanks; ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES10 Minimal Graphical System Equivalent?
If so, has anyone produced a list of all those unneeded packages? Or is it up to each site to try it on their own? (Sure the first 5-10 are easy. But the 60 or so quoted earlier on the list would be tough to guess for most.) This is how I pared it down, from whatever YaST2 selected as the default when I installed. It seems as though there was an obvious way to do this on the SLES10 RC I started testing on, but once I started looking at FCS code the option was either removed, or I simply didn't take good enough notes, because it was not obvious to me how to achieve the same result on FCS. X11 apps such as YaST2 still work remotely, if they must be used. This is in chunks because there were dependency issues to figure out. --begin excerpt from notes 14) clean up software selections. rpm -e \ kdelibs3 \ kdelibs3-32bit rm -rf /opt/kde3/share/icons rpm -e \ libgsf-fnome \ eel \ gedit \ control-center2 \ nautilus-open-terminal \ gal2 \ evince \ eog \ librsvg \ gedit \ susehelp \ file-roller \ nautilus-share \ system-tools-backends \ gnome-media \ gnome-volume-manager \ gdm \ susehelp_en \ gnome-cups-manager \ gnome-keyring-manager \ gnome-screensaver \ gnome-spell2 \ libgnomesu \ gnome-power-manager \ hal-gnome \ gnome-session \ gnome-panel-nld \ gnome-applets \ gnome-utils \ gnome2-user-docs \ gtkhtml2 \ gnome-desktop \ libgnomeprintui \ gnome-main-menu \ yelp \ nautilus rm -rf /etc/opt/gnome/gdm rpm -e \ python-gnome \ gnome-terminal \ gnome-system-monitor \ libgnomeui-32bit \ gnome-keyring-32bit \ gnome-panel-nld-32bit \ gnome-desktop-32bit \ eel-32bit \ nautilus-32bit \ libgnomecanvas-32bit \ gail-32bit \ libbonoboui-32bit \ libgnomeprintui-32bit rpm -e \ gail \ at-spi \ gconf2 \ gconf2-32bit \ evolution-data-server \ evolution-data-server-32bit \ gcalctool \ gconf-editor \ gnome-doc-utils \ gnome-menus \ gnome-menus-32bit \ gnome-nettool \ gnome-vfs2-32bit \ gstreamer010-plugins-base \ gstreamer010-plugins-base-32bit \ gstreamer010-plugins-good \ gucharmap \ libgda \ libgnome-32bit \ librsvg-32bit \ gstreamer010-plugins-base \ gnome-menus \ glib-sharp2 \ gmime \ gtk-sharp2 \ zen-updater \ gnome2-NLD \ gnome-audio \ gnome-printer-add \ gnome-themes \ gtk2-engines \ gtk2-themes \ gtk2-engines-32bit \ gtk-sharp2-32bit \ gtksourceview \ libgnomedb \ iso-codes \ libnotify \ libsexy \ notification-daemon \ libgnomecups \ libgnomeprint \ libgnomecups-32bit \ libgnomeprint-32bit \ metacity \ tango-icon-theme \ vino \ zenity \ libgsf rpm -e \ awesfx \ cdparanoia \ evolution-data-server \ gle \ gstreamer010 \ guile \ jack \ libmusicbrainz \ libraw1394 \ libcddb \ thinkeramik-style \ xscreensaver \ libcdio \ vcdimager rpm -e \ bootsplash \ bootsplash-theme-SuSE-SLES \ cpufrequtils \ usbutils --end excerpt Disclaimers: Typos my responsibility. If there is something you see in the list of packages I removed, which you would like to keep, there may be dependencies to be satisfied. We're just getting ready to roll out SLES10 into production. The list may or may not require amendments once it has to stand up to user scrutiny and demand. ok r. ps. RC = release candidate ; FCS = first customer ship. Sorry, I'm a long-time Sun guy, my glossary is still being udpated with IBM and Linuxisms. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Assigning/Tracking Host names
-Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED] If you remember all that, you must be nearly ready for retirement too:-) Alas, yesterday was my 30th birthday. If I were nearly ready for retirement it would make this pending (potential) outsourcing that I am facing much easier to take. As it is, if it does happen, I'm probably going to have to go back to working on UNIX systems and forget about z/VM, as I will have just barely over two years experience at that point. I think that will be the biggest disappointment of the whole ordeal, for me personally. The anthropology of technology is a sort of hobby of mine. I was thinking though, back to when VTAM was new and folk were naming terminals. No more than eight characters, and they folded a location code and serial number into each name. If someone complained about WACAVT09 not working, probably the responsible person could go, if not to the device itself, at least to the right room. For a huge deployment of equipment which is all essentially functionally undifferentiated (or at least interchangeable), there's a lot to like about that approach. Names based on location and function have their good points. True. In my experience, however, machines change location or function more frequently than they change names. This is probably more true of distributed systems than it is of mainframe systems. I note that for some years (but no longer) there were half-a-dozen or so IP addresses associated with www.ibm.com. I suspect that it is no longer true, not because redundancy and load-balancing such a setup would have afforded is no longer required, but because there are more sophisticated ways of doing it these days than just with multiple DNS A (or CNAME) records. F5 Networks, for example, have done some rather astonishing things with their BigIP product---which honestly has probably moved on to accomplish even more astonishing things since the last time I looked at it four or five years ago. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Assigning/Tracking Host names
On the contrary. It is the users wanting hostnames 8 characters who are grateful that the hostname and VM username need not match. The RFC which Grega mentioned says otherwise. But at this point, we're arguing matters of taste. The RFC was drafted in 1990, at a time when only the newest UNIX systems were capable of handling a hostname longer than 8 characters. There were many UNIX systems still in use which were limited in this way, and limited too, for that matter, to 13 character filenames. In fact, HP-UX couldn't reliably handle hostnames longer than 8 characters for another ten years after this RFC was drafted. Don't forget that you only got 6 characters for a DECNET node name, too, so sometimes it was advisable to limit IP hostnames even further! This is all ancient history, though relevant if your shop is still supporting machines old enough to be affected by these limitations. If so, I feel your pain. That said, host naming conventions are definitely a matter of taste. My personal preference is to anthropomorphize heavily, and assign CNAMEs if you want to name functions or services (i.e. a machine named 'wingnut' which is also known as 'ns3', 'smtp-outgoing', and 'www'). There are a lot of really outstanding reasons why I feel this way, but not everybody agrees. And that's okay, too. Some of the reasons for disagreeing are even reasonable ones. (@; ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Assigning/Tracking Host names
-Original Message-
From: David Boyes [mailto:[EMAIL PROTECTED]
Sent: Monday, April 30, 2007 3:13 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Assigning/Tracking Host names
You could get creative with the MAC address.
Yep. The only trick is that MAC addresses have to be unique
for DHCP to match the interface with the right address. A
small exec could generate the right entries to put on the
NICDEF card in the directory to do that.
You don't really even need to do that. I key the DHCP server on the DHCP
Client ID, which I set to be the VM user name, since we run a layer 3
VSWITCH.
Briefly...
In /etc/sysconfig/network/dhcp on the client:
DHCLIENT_CLIENT_ID=`/usr/bin/awk '/^VM00 Name:/ { print $NF }'
/proc/sysinfo`
In dhcpd.conf on the server, for a VM user LNX20026:
host lnx20026 {
option dhcp-client-identifier 00:4c:4e:58:32:30:30:32:36; #
\0LNX20026
option host-name install-test;
fixed-address 192.54.6.160;
}
Then it doesn't matter what the MAC addresses are. I'm polishing an ifup
script right now to take care of changing config files after DHCP lease
information changes (i.e. after cloning, or during a DR), which should
be the last piece I need for total world domination.
ok
r.
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Assigning/Tracking Host names
-Original Message- From: David Boyes [mailto:[EMAIL PROTECTED] That trick works because you're depending on the layer 3 fixup code in the OSA to sort things out, since in that situation all the guest frames have the physical MAC of the OSA. The second one of those interfaces has to talk to something outside the box on a layer 2 VSWITCH, then the MACs have to be unique. Eh? I run layer 3. I have to rely on the OSA code to sort things out whether DHCP is in the picture, or not. I couldn't easily in this situation, however, rely on a DHCP server not on my VSWITCH, no. I'm perfectly aware of that. My DHCP server is a tiny SLES9 user under VM, on the same layer 3 VSWITCH as all my clients, so it's not an issue. If I had the luxury of running a layer 2 VSWITCH, I could still key on the DHCP Client ID field like I am now, but with the added benefit of potentially being able to be served by a DHCP server on a different network (which in my case would be run by somebody else anyway, so it's not a win). Sending a DHCPDISCOVER with a Client ID for the server to key on is not a function of layer 2 or layer 3; think about PPPoA and how all those cablemodem or DSL DHCP clients out there work. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: CPINT error when issuing HCP commands under SLES10
'modprobe cpint' and try it again. our SLES10 test image is doing the same thing; our resident Linux white-hat gave me a couple clues on what to check to find out WHY. I'll report back with my discovery unless somebody else pipes up with the answer, first. ok r. -Original Message- From: Peter E. Abresch Jr. - at Pepco [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 2:29 PM To: LINUX-390@VM.MARIST.EDU Subject: CPINT error when issuing HCP commands under SLES10 I have the following installed on a newly installed sles10x: cpint-kmp-default-2.5.3_2.6.16.21_0.8-3.2 cpint-2.5.3-3.2 However, when I issue any HCP command, I get the following: linuxm01:/var/log/YaST2 # hcp q stor Open: No such file or directory Even when I run: linuxm01:/etc/init.d # ./cpint.init start insmod: can't read 'cpint': No such file or directory What am I missing? Peter This Email message and any attachment may contain information that is proprietary, legally privileged, confidential and/or subject to copyright belonging to Pepco Holdings, Inc. or its affiliates (PHI). This Email is intended solely for the use of the person(s) to which it is addressed. If you are not an intended recipient, or the employee or agent responsible for delivery of this Email to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. If you have received this message in error, please immediately notify the sender and permanently delete this Email and any copies. PHI policies expressly prohibit employees from making defamatory or offensive statements and infringing any copyright or any other legal right by Email communication. PHI will not accept any liability in respect of such communications. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
dmsetup suspend
Can somebody help me understand the practical aspects of this statement from dmsetup(8) ? suspend device_name Suspends a device. Any I/O that has already been mapped by the device but has not yet completed will be flushed. Any further I/O to that device will be postponed for as long as the device is suspended. Specifically, I am researching possible approaches to solving the problem of guaranteeing good DR backups and reliable clones of running Linux users in combination with the CP FLASHCOPY facility of our DS8100. The new AF_IUCV support will probably prove necessary in the effort, as well as the asynchronous FLASHCOPY we're promised in z/VM 5.3. The statement to the effect that I/Os which have been mapped but not completed will be flushed is of some concern, but I am unsure of the potential danger I would be exposing myself to, in any real terms. Should it be a small concern? A large concern? My intial experimentation seems to suggest it works in practice (given my small sample size), but what are the theoretical dangers? I get a better feeling from the 'freeze' capabilities of xfs, but as deploying it in preference to something which uses the 'suspend' capabilities of the device_mapper involves getting our distrubted systems people to buy off on adopting xfs as the standard filesystem for linux on zSeries, I would like to exhaust the possibilities of 'dmsetup suspend', first. This would be on SLES10; I am aware of the kernel panics people are reporting with RHEL5 on intel systems and am assuming, for now, that it is a non issue in our SuSE/zSeries environment (given I've been playing with it and haven't seen a kernel panic myself). ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: AF_IUCV support
-Original Message- From: Dave Jones [mailto:[EMAIL PROTECTED] Since IUCV is now built-in to both CMS and Linux, you could develop cloning applications that used an IUCV connection to set up cloned Linux guests IP and other parameters. Or have CMS and Linux applications share data and communicate using IUCV; much simpler and faster than having to do an IP network setup. I'm curious why you would prefer this solution for cloning over, say, not keeping IP network information on the Linux image at all and using DHCP with static leases, instead. ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
problem with DHCP in SLES10 again, this time with z/VM 5.2
Thanks to the help of the kind folks on this list, I got DHCP working with SLES10 under z/VM 5.1 several months ago. I set the project aside for a while while we worked on migrating to z/VM 5.2. Now I'm picking it up again, and to my surprise, it's broken. HCPIPN2833E Error 'E00A'X adding IP address xxx.xxx.xxx.16 for VSWITCH SYSTEM xxx. HCPIPN2833E IP address is already in use on the LAN. The address is not in use. I can 'ifdown' and it disappears from Q LAN DETAILS. If I avoid using DHCP, I can manually configure the interface using the same address the VSWITCH claims is already in use, and everything works correctly with no message. If I 'ifup' and use DHCP, I get the above message, an IP address in Local mode on the VSWITCH, and a non-communicative Linux user. The DCHP assignment is working, as the Linux user receives the correct IP address and hostname from the DHCP server, but that's when the VSWITCH shuts me down. I have 'fake_ll=1' set (layer 3), as well as 'ARP=no' (which was the proper magic for SLES10 with z/VM 5.1). We're at z/VM service level 0601, with VMLAN latest service VM63850. What am I missing? ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: problem with DHCP in SLES10 again, this time with z/VM 5.2
I have ARP=no set, which got rid of the error when I ran into it the first time under z/VM 5.1. It's still set, but doesn't seem to be doing anything anymore (or at least it's not solving my problem anymore). ok r. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED] Sent: Friday, January 12, 2007 3:08 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: problem with DHCP in SLES10 again, this time with z/VM 5.2 According to http://www2.marist.edu/htbin/wlvtype?LINUX-VM.63649 you might try setting ARP=NO for a VSWITCH operating in layer 3 mode. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Stricklin, Raymond J Sent: Friday, January 12, 2007 5:44 PM To: LINUX-390@VM.MARIST.EDU Subject: problem with DHCP in SLES10 again, this time with z/VM 5.2 Thanks to the help of the kind folks on this list, I got DHCP working with SLES10 under z/VM 5.1 several months ago. I set the project aside for a while while we worked on migrating to z/VM 5.2. Now I'm picking it up again, and to my surprise, it's broken. HCPIPN2833E Error 'E00A'X adding IP address xxx.xxx.xxx.16 for VSWITCH SYSTEM xxx. HCPIPN2833E IP address is already in use on the LAN. The address is not in use. I can 'ifdown' and it disappears from Q LAN DETAILS. If I avoid using DHCP, I can manually configure the interface using the same address the VSWITCH claims is already in use, and everything works correctly with no message. If I 'ifup' and use DHCP, I get the above message, an IP address in Local mode on the VSWITCH, and a non-communicative Linux user. The DCHP assignment is working, as the Linux user receives the correct IP address and hostname from the DHCP server, but that's when the VSWITCH shuts me down. I have 'fake_ll=1' set (layer 3), as well as 'ARP=no' (which was the proper magic for SLES10 with z/VM 5.1). We're at z/VM service level 0601, with VMLAN latest service VM63850. What am I missing? ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: problem with DHCP in SLES10 again, this time with z/VM 5.2
Alan; I had been looking at the Hints and Tips site while attempting to troubleshoot the problem. I do not see anything relevant that I have not already tried. Was there some advice in particular you had in mind? I am aware that layer 2 VSWITCH is the way to go. Unfortunately, we deployed VSWITCH in z/VM 4.4, when it was layer 3 only. All of our production linux users are using the VSWITCH now, and I don't understand how we can effectively migrate our users to layer 2 given the limitation that a VSWITCH of one type will not intercommunicate with a VSWITCH of the other. I'll look at getting the new maintenance applied. ok r. -Original Message- From: Alan Altmark [mailto:[EMAIL PROTECTED] Sent: Friday, January 12, 2007 3:48 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: problem with DHCP in SLES10 again, this time with z/VM 5.2 On Friday, 01/12/2007 at 02:43 PST, Stricklin, Raymond J [EMAIL PROTECTED] wrote: Thanks to the help of the kind folks on this list, I got DHCP working with SLES10 under z/VM 5.1 several months ago. I set the project aside for a while while we worked on migrating to z/VM 5.2. Now I'm picking it up again, and to my surprise, it's broken. HCPIPN2833E Error 'E00A'X adding IP address xxx.xxx.xxx.16 for VSWITCH SYSTEM xxx. HCPIPN2833E IP address is already in use on the LAN. Please see http://www.vm.ibm.com/virtualnetwork/hints.html. I know you have ARP=no, but check the other recommendations as well. Also, there is additional maintence available beyond VM63850. Please see http://www.vm.ibm.com/virtualnetwork/mntlvl52.html. Finally, layer 2 doesn't have this problem with IP address management since communications are at the MAC layer and ARPs (real or virtual) are used. Consider that as an alternative. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DHCP over VSWITCH?
For the benefit of the rest of the list; Alan's suggestion to enable faked frame headers solved the problem I was having. Unfortunately, a second problem surfaced immediately. The VSWITCH would give me an error when the DHCP client received its lease: HCPSWU2833E Error 'E00A'X adding IP address 192.54.6.16 for VSWITCH SYSTEM VLINUX1. HCPSWU2833E IP address is already in use on the LAN. There is no other machine (real or virtual) on the network with this address. I could have ignored the message except that the DHCP client will then only respond to other machines on the VSWITCH. It will not communicate with the router on the subnet (nor consequently with any machine outside of the subnet). I left the user logged off overnight; when I logged it on this morning it started up, received its DHCP lease without triggering the VSWITCH error, and was communicating normally on the network, with both other VSWITCH users and with the rest of the world. As soon as I rebooted it, I began to receive the VSWITCH errors again. After asking Dr Google, I found that I needed to add the line ARP='no' to /etc/sysconfig/network/ifcfg-qeth-bus-ccw-0.0.a001 (our NIC dev) for an IP VSWITCH. We've been using IP VSWITCH without DHCP for about a year, and why we never ran into this problem before, I couldn't exactly say. http://www.vm.ibm.com/virtualnetwork/hintarp.html IBM: z/VM Virtual Networking Hints and Tips - Error x0002, xE00A We've been using IP VSWITCH without DHCP for about a year, and why we never ran into this problem before, I couldn't exactly say. As of right now it looks a lot like we have what we need for a successful DHCP implementation. Thanks, everybody. ok r. -Original Message- From: Alan Altmark [mailto:[EMAIL PROTECTED] Sent: Thursday, August 24, 2006 3:18 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: DHCP over VSWITCH? On Thursday, 08/24/2006 at 01:33 MST, Stricklin, Raymond J [EMAIL PROTECTED] wrote: I am trying to set up DHCP for linux users on our VSWITCH. Right now I have two linux users, both on VSWITCH. One is the DHCP server (SLES9 SP2 with ISC dhcpd), and one is the DHCP client (SLES10 with dhcpcd). The client sends its VM user name as its DHCP client identifier; the server assigns a fixed address using that instead of the ethernet MAC address, as our VSWITCH is running in layer 3. Easiest is to change to use a Layer 2 VSWITCH (TYPE ETHERNET). To use DHCP with Layer 3, you have to get the device driver to generate fake ethernet frame headers. E.g. For NIC A000 on SLES9: /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.a000: CCW_CHAN_IDS='0.0.a000 0.0.a001 0.0.a002' CCW_CHAN_MODE='OSAPORT' CCW_CHAN_NUM='3' MODULE='qeth' MODULE_OPTIONS='' SCRIPTDOWN='hwdown-ccw' SCRIPTUP='hwup-ccw' SCRIPTUP_ccw='hwup-ccw' SCRIPTUP_ccwgroup='hwup-qeth' STARTMODE='auto' QETH_OPTIONS='fake_ll=1' look here! Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
DHCP over VSWITCH?
I am trying to set up DHCP for linux users on our VSWITCH. Right now I have two linux users, both on VSWITCH. One is the DHCP server (SLES9 SP2 with ISC dhcpd), and one is the DHCP client (SLES10 with dhcpcd). The client sends its VM user name as its DHCP client identifier; the server assigns a fixed address using that instead of the ethernet MAC address, as our VSWITCH is running in layer 3. It's partly working right now. The client sends its DHCPDISCOVER. This is received by the server, which sends its DHCPOFFER. The DHCPOFFER is never received by the client. Here is a tcpdump on the client. You can see it sending DHCPDISCOVER: 27 769.364929 0b.00.0a - 00.7f.f9 FC Unknown frame 28 833.397832 0.0.0.0 - 255.255.255.255 DHCP DHCP Discover - Transaction I D 0x7ff9580b 29 833.409721 0b.00.0a - 00.7f.f9 FC Unknown frame 30 897.567832 0.0.0.0 - 255.255.255.255 DHCP DHCP Discover - Transaction I D 0x7ff9580b 31 897.572165 0b.00.0a - 00.7f.f9 FC Unknown frame Here is what's going on at the same time, from the server's point of view, receiving DHCPDISCOVER and sending the DHCPOFFER: 0.00 0.0.0.0 - 255.255.255.255 DHCP DHCP Discover - Transaction ID 0 x7ff9580b 0.000164 0.0.0.0 - 255.255.255.255 DHCP DHCP Discover - Transaction ID 0 x7ff9580b 0.005826 192.54.6.17 - 255.255.255.255 DHCP DHCP Offer- Transaction ID 0 x7ff9580b 0.008912 192.54.6.17 - 255.255.255.255 DHCP DHCP Offer- Transaction ID 0 x7ff9580b 0.009443 192.54.6.17 - 255.255.255.255 DHCP DHCP Offer- Transaction ID 0 x7ff9580b 0.011666 192.54.6.17 - 255.255.255.255 DHCP DHCP Offer- Transaction ID 0 x7ff9580b This is as far as we get. What is preventing the DHCPOFFER from being received by the client? I don't understand how this could be only half-broken (the IP broadcast works in one direction, but not the other). Is there some patch or APAR we're missing? I really, really hope we don't have to reconfigure our VSWITCH to layer 2 to make this work. Thanks; ok r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
