Re: [CMS-PIPELINES] STATE on SFS w/o ACCESS
PIPE AHELP is the formal definition of the pipeline on z/VM. Just as the Author's edition is the formal book. -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: patching frequency
On the topic of patching, we have our first test Linux server up and running. Being new to Linux, what tool and process is used by most to maintain the servers? Reading the RH Cookbook 5.2 chapter 11 talks about using RPM and yum. Is this where I get started? -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Levy, Alan Sent: Thursday, August 18, 2011 9:22 AM To: LINUX-390@VM.MARIST.EDU Subject: patching frequency How often do you patch your linux servers. I have been patching once every 3-4 months (over 100 servers - sles 9 thru 11) and have been told that I had to start patching much more frequently. I'd like to find out what other people are doing. Thank you -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/ -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: udevd-349-: nss_ldap: failed to bind to LDAP server ldap:// . . .
Thanks for responding. I agree that changing the order to ?files ldap? for passwd, shadow, and group will eliminate the overly burdensome messages, I question if this is the correct approach. All our external information is stored in LDAP and is intended to be share with multiple Linux systems. Some IDs are defined locally and to LDAP as these IDs would be used when there are LDAP issues that cause authentication issues. I made the change as suggested and with some slight PAM config changes, confirmed that these messages are eliminated. However, I am thinking that we would still rather go to LDAP first and files second. I understand that these messages are produced because the network is not available and communications to the ldap server is lost. This occurs during shutdown and IPL. I believe this is why the LDAP parameter nss_initgroups_ignoreusers was developed. By specifying a list of known local users that will be running between network availability and network unavailability in the nss_initgroups_ignoreusers, that NSS will simply return a notfound condition. Of course this parameter can also be used to prevent a wasted LDAP lookup for local users we know are not defined to ldap. The default nss action is to continue so when we have ?ldap files?, the call to ldap is bypassed and we move on to files. It is my understanding that the notfound condition is immediately passed thus eliminating any ldap interaction for those users specified in nss_initgroups_ignoreusers. I have the following specified: nss_initgroups_ignoreusers root,ldap,haldaemon,messagebus,dbus,bin,daemon,postfix,sshd,polkituser,uuidd,100,101 I know I probably only need a few of these but I wanted to eliminate the messages. This does not appear to be working as expected. Of course my expectations could be off. What are everyone?s thoughts on this? Is this an issue that I need to push to support? What are others doing with Linux RACF LDAP authorizations? All comments are welcome. Thanks Peter From: Patrick Spinler spinler.patr...@mayo.edu To: LINUX-390@vm.marist.edu Date: 08/18/2011 03:37 PM Subject:Re: udevd-349-: nss_ldap: failed to bind to LDAP server ldap:// . . . Sent by:Linux on 390 Port LINUX-390@vm.marist.edu Your nsswitch says to search ldap before anything local. I use passwd: files ldap (same for shadow group). Thus, it never even tries ldap if it finds a local entry. This has also come in handy for a few weird exceptions where the application absolutely had to do something weird and exceptional: I could override it on the local box. For example, two apps which absolutely had to use the same group name, with different memberships. Here, we have an enterprise oracle group with dozens of hosts for which their dba's are all members of a common group. We also have a couple of one off oracle hosts for non-enterprise groups who want the same names but different memberships. It's a bit of a pain to manage those specific host exceptions, but at least it's possible using 'files ldap'. -- Pat On 8/18/11 12:47 PM, Peter E. Abresch Jr. - at Pepco wrote: I have the following set in /etc/ldap.conf bind_policy soft nss_initgroups_ignoreusers root,ldap,haldaemon,messagebus,dbus,bin,daemon,postfix,sshd,polkituser,uuidd,100,101 However, these messages are overwhelming. I get them for udevd and vol_id. These might be a startup timing issue as soon as the network is available, they go away. However, the nss_initgroups_ignoreusers should ignore this. Am I still missing something? /etc/nsswitch.conf contains: passwd: ldap compat shadow: ldap compat group: ldap compat hosts: files dns networks: files dns services: files protocols: files rpc:files ethers: files netmasks: files netgroup: files nis publickey: files bootparams: files automount: files nis aliases:files From: Peter E Abresch/EP/PEP To: LINUX-390@vm.marist.edu Date: 08/18/2011 09:00 AM Subject:udevd-349-: nss_ldap: failed to bind to LDAP server ldap:// . . . We finally have RACF LDAP server running on z/OS with the TDBM backend and native authentication. We thought we were done as all our testing completed successfully. However, when the operator booted Linux, the console is flooded with the following messages on the shutdown and startup. It is very difficult to catch a real error with these flood of messages. Also, these messages are somewhat misleading as the LDAP server is up and running and available. I am thinking that these messages are produced as some service is shutdown and before some service starts. Here is the challenge: How can we eliminate these messages during shutdowns and boots? There are all coming from udevd. Thanks in advance. Peter udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't contact LDAP server udevd-349-:
Re: patching frequency
On 08/19/2011 07:51 AM, Dazzo, Matt wrote: On the topic of patching, we have our first test Linux server up and running. Being new to Linux, what tool and process is used by most to maintain the servers? Reading the RH Cookbook 5.2 chapter 11 talks about using RPM and yum. Is this where I get started? That's unfortunately a fairly lengthy discussion. It really all depends. Some of the variables are: *) what distro you're running *) what vendor/distro supplied and what local repositories you have (or can create) to patch from *) do you want to run patches locally from each server, or push them from a central service *) what your patching constraints, requirements, and goals are etc, etc, etc. For example, for a redhat system, if you have redhat network access, you can point your linux server straight at rhn.redhat.com, and do a yum upgrade. However, what you get from that is whatever patches are available at that moment in time. Next week might have newer patches, which may make a difference if you e.g. do a dev server one week, and it's production counterpart a week later -- can you tolerate dev potentially being different than prod? You could paper over that by setting up a process to pull software from rhn.redhat.com and setting up a local yum repo, with fixed, known packages to patch from, but that's a pile of work. You could also set up spacewalk and/or purchase satellite to help automate that process and slap a pretty gui on top of it (and do provisioning as well), but again their's cost and time tradeoffs. All this changes, of course, if you're running SLES or Centos or Debian or the like, to whatever their distro specific patching infrastructure is. Seriously, this is worthy of a presentation or two at a conference. I'd volunteer for it, but our travel budget is more or less non-existent. :-( Maybe a whitepaper from some helpful vendor? (hint hint) -- Pat -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: patching frequency
We are currently redhat 5.6. Ug nothing like SMPE for the mainframe. I guess this is all going to depend on what applications we run and how many servers we eventually use. Anybody else? What's your process for maintenance? -Original Message- From: Patrick Spinler [mailto:spinler.patr...@mayo.edu] Sent: Friday, August 19, 2011 11:40 AM To: Linux on 390 Port Cc: Dazzo, Matt Subject: Re: patching frequency On 08/19/2011 07:51 AM, Dazzo, Matt wrote: On the topic of patching, we have our first test Linux server up and running. Being new to Linux, what tool and process is used by most to maintain the servers? Reading the RH Cookbook 5.2 chapter 11 talks about using RPM and yum. Is this where I get started? That's unfortunately a fairly lengthy discussion. It really all depends. Some of the variables are: *) what distro you're running *) what vendor/distro supplied and what local repositories you have (or can create) to patch from *) do you want to run patches locally from each server, or push them from a central service *) what your patching constraints, requirements, and goals are etc, etc, etc. For example, for a redhat system, if you have redhat network access, you can point your linux server straight at rhn.redhat.com, and do a yum upgrade. However, what you get from that is whatever patches are available at that moment in time. Next week might have newer patches, which may make a difference if you e.g. do a dev server one week, and it's production counterpart a week later -- can you tolerate dev potentially being different than prod? You could paper over that by setting up a process to pull software from rhn.redhat.com and setting up a local yum repo, with fixed, known packages to patch from, but that's a pile of work. You could also set up spacewalk and/or purchase satellite to help automate that process and slap a pretty gui on top of it (and do provisioning as well), but again their's cost and time tradeoffs. All this changes, of course, if you're running SLES or Centos or Debian or the like, to whatever their distro specific patching infrastructure is. Seriously, this is worthy of a presentation or two at a conference. I'd volunteer for it, but our travel budget is more or less non-existent. :-( Maybe a whitepaper from some helpful vendor? (hint hint) -- Pat -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: RACF and sysprog ID
On Thursday, 08/18/2011 at 12:56 EDT, Troy A Slaughter t...@ntrs.com wrote: I'm trying to figure out the best way to define authority to a SYSPROG group under RACF/VM. I don't want SYSPROG members to have all authority so I don't want to just add SPECIAL and OPERATION attributes to the group. But they should be able to perform system-wide list operations and such. I also want them to have certain system display capabilities. It seems the only way to do that is via privilege classes. If I'm right, it looks like I will be doing a combination of RACF alterations to the SYSPROG group as well as privilege class changes to the individual system IDs. Even with RACF (or any other security product), the vast majority of CP commands and functions continue to be controlled by the CP privilege class and the OPTION statement in the directory. RACF cannot *add* commands to a virtual machine's command set; it can only *disallow* commands and functions they have access to. Specifically, CP allows RACF to limit: - STORE HOST - FOR - TRSOURCE - XAUTOLOG - Diagnose 0xE4 - Diagnose 0x88 So just make sure all the virtual machines in your SYSPROG group have privilege classes ABCDEG. Disclaimer: Once you give someone class C authority and the ability to modify SYSTEM CONFIG, they can do whatever they want., up to and including giving themselves SPECIAL and OPERATIONS authority, as well as the ability to issue the above commands/diagnose. While there are RACF techniques to make that mountain more difficult to climb, the mountain top is still attainable. Dealing with this is on the To Do list, but it comes under the heading of Be careful what you wish for - you might get it. Full separation of duties on z/VM (and z/OS, btw) is not based on technology, but depends on the personal integrity of the system programmers. Until we have M5 or SkyNet, the humans remain firmly in control of the machines. (Fvvo firmly.) Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: udevd-349-: nss_ldap: failed to bind to LDAP server ldap:// . . .
On 8/19/2011 at 10:53 AM, Peter E. Abresch Jr. - at Pepco peabre...@pepco.com wrote: I have the following specified: nss_initgroups_ignoreusers root,ldap,haldaemon,messagebus,dbus,bin,daemon,postfix,sshd,polkituser,uuidd ,100,101 I know I probably only need a few of these but I wanted to eliminate the messages. This does not appear to be working as expected. Of course my expectations could be off. What are everyone?s thoughts on this? Is this an issue that I need to push to support? What are others doing with Linux RACF LDAP authorizations? All comments are welcome. Thanks A Google search found something that indicates perhaps having too many users listed can be a problem. They were able to get the ignore list to work with 2 entries, but having 13 didn't. This was on RHEL5 from June of this year, so fairly recent. Give that a try and see what happens. Then regardless of the result, open up a support request. 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: patching frequency
We are currently redhat 5.6. Ug nothing like SMPE for the mainframe. I guess this is all going to depend on what applications we run and how many servers we eventually use. Anybody else? What's your process for maintenance? You will live to regret using anything but RPM to package and deliver service and configuration (we use it for configuration files as well as official maintenance, and recommend others do so as well). Yum delivers and installs RPMs, works very well for both RH and SuSE. Not as nice as apt-get for Debian, but that's the stuff RH/SuSE are smoking. Set up a local repository for your gold level of maintenance. If the package comes from the distribution vendor, copy it to your local repository so that you know precisely what you're getting until you consciously upgrade the local repository. 'man createrepo' for the gory details. If you use RPM to deliver configuration, set up a separate repository for that so you don't clobber something accidentally. We use the host name as the name of a configuration package, and when you update a server, update the package for that server and then do 'yum update' on that server. That way you know exactly what configuration files are deployed on that server by a simple 'rpm -qa' and you can reference those back to a CMDB entry or however you track configuration. -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: udevd-349-: nss_ldap: failed to bind to LDAP server ldap:// . . .
Thanks, I saw that, the default is root,ldap but that did not make a difference. I also tried other combinations and a couple of times with only root with the same results. There are many hits on a google search for this condition but no resolutions. I am seeing this condition for udevd, securitytty, and some othe services. I assume these all run under root as there are no ids or groups specifically for udevd and the rest. I am kind of stumped. I am leaning towards a possible bug at this point. Maybe something will come to be over a couple (or six) beers this weekend. Peter From: Mark Post mp...@novell.com To: LINUX-390@vm.marist.edu Date: 08/19/2011 02:45 PM Subject:Re: udevd-349-: nss_ldap: failed to bind to LDAP server ldap:// . . . Sent by:Linux on 390 Port LINUX-390@vm.marist.edu On 8/19/2011 at 10:53 AM, Peter E. Abresch Jr. - at Pepco peabre...@pepco.com wrote: I have the following specified: nss_initgroups_ignoreusers root,ldap,haldaemon,messagebus,dbus,bin,daemon,postfix,sshd,polkituser,uuidd ,100,101 I know I probably only need a few of these but I wanted to eliminate the messages. This does not appear to be working as expected. Of course my expectations could be off. What are everyone?s thoughts on this? Is this an issue that I need to push to support? What are others doing with Linux RACF LDAP authorizations? All comments are welcome. Thanks A Google search found something that indicates perhaps having too many users listed can be a problem. They were able to get the ignore list to work with 2 entries, but having 13 didn't. This was on RHEL5 from June of this year, so fairly recent. Give that a try and see what happens. Then regardless of the result, open up a support request. 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 more information on Linux on System z, visit http://wiki.linuxvm.org/ 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 lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Rhnsd?
Hi Bobby, Can you check further back in the older logs (/var/log/update-date if you have logrotate installed) to see if this is the 12th up2date checkin? What may be happening is that rhnsd is designed to check in regularly 11 times, then on the 12th time it applies some random jitter to the time (to avoid lots of systems checking in at the same frequency all the time). After that it resumes the 4 hour checkins. -- Brad Hinson bhin...@redhat.com Worldwide System z Sales, Strategy, Marketing Red Hat, Inc. +1 (919) 360-0443 http://www.redhat.com/z On Aug 18, 2011, at 11:50 AM, Bauer, Bobby (NIH/CIT) [E] wrote: In our RHEL 6, there is an RHNSD task that the man page says queries 'Red Hat Network for updates and information'. It is suppose to check in every 4 hours, the default, this is also specified in /etc/sysconfig/rhn/rhnsd. According to /etc/init.d/rhnsd it uses /etc/sysconfig/rhn/up2date as its config file. In here specifies logging as /var/log/up2date Looking at /var/log/up2date it appears the 4 hour default is ignored. In fact, I'm not sure what interval it is using: [Thu Aug 18 02:21:30 2011] up2date logging into up2date server [Thu Aug 18 02:21:34 2011] up2date successfully retrieved authentication token from up2date server [Thu Aug 18 03:51:26 2011] up2date logging into up2date server [Thu Aug 18 03:51:29 2011] up2date successfully retrieved authentication token from up2date server [Thu Aug 18 06:21:30 2011] up2date logging into up2date server [Thu Aug 18 06:21:33 2011] up2date successfully retrieved authentication token from up2date server [Thu Aug 18 09:54:50 2011] up2date logging into up2date server [Thu Aug 18 09:54:54 2011] up2date successfully retrieved authentication token from up2date server The RHN web page indicates the server Checked In: 8/18/11 10:21:34 AM EDT Using the RHN web page, I specified 4 fixes to be pushed to this server and I expected it to happen when the server checked in. It didn't. So can anybody explain the time that time intervals we are seeing and when RHN will actually push fixes to a server? Thanks Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/ -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
