Re: different take on Java 6 question
Mark Post wrote: On 11/21/2008 at 10:07 AM, [EMAIL PROTECTED] wrote: found the IBM link for jdk downloads - now a different question. Will the 31-bit jdk work - and work well - in a 64-bit linux environment. We run the 32-bit java on 64-bit AIX without any difficulty since quite a few of our apps refuse to work with the 64-bit java. Don't have any experience in the linux world with this, though. The recommendation I've heard from IBM is to run 31-bit if at all possible. It's largely going to depend on the heap size you need for your application. Applications drive the java requirement - SAP requires the 64bit IBM SDK. This opens another ongoing peeve of mine... Novell-Suse ship the IBM javas on the DVD and supply updates - great job! Also nice work on the /etc/alternates and the update-alternatives command - all very nice if you need to run multiple levels of java at the same time. But these rpms install into /usr, the rpms from the IBM website install into /opt. SAP recommends that one should use the java from the IBM website because IBM often posts updates before Novell-Suse can which kind of defeats all the good work done by Novell-Suse :-( It would be nice if the two companies could sync-up on how the rpms should be packaged. 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
Re: STOP SYSTEM VIRTUAL MACHINES EXPIRING?
THAT CLEARS IT UP COMPLETELY. THANKS ALL EXPired password does not cause any problems unless you try to logon to the server. During system IPL the servers get autologged and that does not reference the password. This is why we say it is Very Best Practice to define all these servers with the NOPASSWORD option. That avoids these problems. Rob -- 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 ** This email is confidential and may contain copyright material of the John Lewis Partnership. If you are not the intended recipient, please notify us immediately and delete all copies of this message. (Please note that it is your responsibility to scan this message for viruses). Email to and from the John Lewis Partnership is automatically monitored for operational and lawful business reasons. ** John Lewis plc Registered in England 233462 Registered office 171 Victoria Street London SW1E 5NN Websites: http://www.johnlewis.com http://www.waitrose.com http://www.greenbee.com http://www.johnlewispartnership.co.uk ** -- 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: Some observations regarding admining rhel v. sles on Z
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shawn Wells wrote: Hi Patrick, I thought I'd take the chance to respond to this, publicly, since I haven't seen any other threads. ... *) Integration to the Z platform The zipl issues were fixed and will be released in RHEL 5.3, https://bugzilla.redhat.com/show_bug.cgi?id=381201. Brad Hinson (who many people on this list know) was the champion of getting this pushed through. Thanks Brad, and Shawn! A couple of other notes about s390 integration, since I didn't want to put everything in my first message: *) mkinitrd mkinitrd in SuSE is notably more convenient, in two ways. One s390 specific way, and one architecture neutral way: +) It automagically pulls the current list of activated DASD channel numbers, and includes those in the ramdisk image it builds for activation at next IPL. No forgetting to edit /etc/modules.conf when extending a machine with more DASD. +) It automagically builds a initrd for every installed kernel in /boot, unless given just a specific kernel by command line options. Not having mandatory options for mkinitrd is sweet. *) Device management It's convenient and easy in YaST to, for example, bring a new DASD online, dasdfmt it, partition it, and add it to a volume group. But using system-config-lvm? Not so easy. In fact, the information it displays is outright incorrect. Enough so that I'm quite adverse to trying to use it and messing things up. On one machine, for example, it shows /dev/dasdc under the list of Uninitialized entities, despite the fact that /dev/dasdc1 is a active PVM in an active volume group. I can't comment on other device types, e.g. qeth devices, because we do those so infrequently in comparison. Out of curiosity, where do you (and ultimately, everyone else on the list) turn to for this information? Are you familiar with Red Hat's Knowledge Base (http://kbase.redhat.com) and Novell's support center (http://www.novell.com/support/microsites/microsite.do)? Always a good one is the Linux documentation project: http://tldp.org/ I mostly use google. Sometimes google points out an article in kbase or Novell's support center. Sometimes I get a good hit on a blog or email list archive. Of course typing system-configtabtab at a terminal gives you a list of installed configuration tools, but you have to be taught to do that in the first place. On the flip side, a real strength of AIX's SMIT and SMITTY administration tools compared to YaST is that they show you exactly what they are changing and what commands they're running. Would it really be so hard to throw a --show-action flag on the system-config toolchain, and a simple GUI front end on top of them? *) Another addition to my list, but one I didn't talk about in comparison was documentation. Here I have to comment that for new Redhat facilities the documentation is often missing or incomplete. For example, when RHEL 5 first hit I set up a test host to mess around with Xen virtualization. The RHEL 5 Virtualization manual was flat out incorrect in what the packaged management tools could do -- there was a bunch of unimplemented functionality that the manuals none-the-less documented. Ditto trying to figure out the new LVM based software mirroring. The documentation was mostly just plain missing when the feature was released, and still pretty damn sparse and hard to find and use even today. Ditto again when I was trying to prototype Redhat Satellite here this last spring. We had our local customer rep come and help us do the install, and he ended up spending considerable time on the phone and internal chat channels to redhat engineers getting our setup running. To be fair to Marc, who did really yeoman duty for us, we were installing into a Xen virt when that was not explicitly listed as being supported. Never the less the errors were obscure, confusing, and mysterious. That's a bit beyond the hope of mere mortals who have only public facing documentation to work from. The situations with virt management tools and satellite have both improved a lot over the past year, but my point is the problems when I first encountered them. *) Updating / patching the system Here, Redhat really shines. Why, thank you ;) One area where both Redhat and SLES need some work is in terms of putting out discrete, reversible patch sets. On Solaris and AIX both (been too long away from HP-UX to comment), it's easy to apply a coherent Patchset Foo 20.3.5, and to roll that patchset out if needed. On e.g. redhat, if I say yum update for a dev box on monday of week 1, by the time I get through test and qa to production on friday of week 3, I'm applying different patches. And if any of them break, I'm forced to go back and by hand apply a few dozen or hundred point revision RPM's. Yes, Satellite is supposed to let you do this. Compared to other big *nix vendors though, that's pushing the patch packaging work onto me. Perhaps an
Re: SLES 10 SP 2 - OSA-Express Setup Assistance
Hi Mark, No, I don't believe so. But I'm still within my trial period. I'll place a call. Dave Dave Stuart Prin. Info. Systems Support Analyst County of Ventura, CA 805-662-6731 [EMAIL PROTECTED] Mark Post [EMAIL PROTECTED] 11/21/2008 12:40 PM On 11/19/2008 at 5:58 PM, David Stuart [EMAIL PROTECTED] wrote: Hi Mark, I'm configuring via YaST(2), as that's what I'm most familiar with. Do you have a support contract with Novell for SLES on z? If so, please open up an SR. 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 -- 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: Some observations regarding admining rhel v. sles on Z
On Nov 24, 2008, at 10:53 AM, Patrick Spinler wrote: +) It automagically pulls the current list of activated DASD channel numbers, and includes those in the ramdisk image it builds for activation at next IPL. No forgetting to edit /etc/modules.conf when extending a machine with more DASD. +) It automagically builds a initrd for every installed kernel in /boot, unless given just a specific kernel by command line options. Not having mandatory options for mkinitrd is sweet. This is also a PITA if you're, for instance, attempting to add diag support to an existing disk. I find its helpfulness pretty irritating as soon as I want to do anything more complicated than adding or removing disks. Adam -- 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: Some observations regarding admining rhel v. sles on Z
John Summerfield wrote: Shawn Wells wrote: Honestly, this may be more of a sendmail vs postfix issue than SLES vs RHEL. But I am glad the process was easy. Not really. I used to use sendmail (OS/2 and Linux). I now choose to use postfix, though I can take care of sendmail if needs be. Without the m4 macros, postfix is way easier to configure. It's easy to maintain, and there's no need to put things that administrators need care about in strange places. I'd argue you just proved my point: The *configuration* issues of the service have little to do with RHEL or SLES, and more to do with the actual service itself. In general, SuSE is a more strongly GUI'ish system, and Redhat is heavily command line, with individual GUI tools if you happen to know how to find them. Out of curiosity, where do you (and ultimately, everyone else on the list) turn to for this information? Are you familiar with Red Hat's Knowledge Base (http://kbase.redhat.com) and Novell's support center (http://www.novell.com/support/microsites/microsite.do)? I've been criticising Red Hat's approach to configuration tools for years. After trying out SUSE, I discovered YAST addresses one of my concerns, the ease of finding and using configuration tools. Hence the naming scheme of the Red Hat config tools: system-config-* Yes, they're not in a YaST-ish tool, but at least they're all named the same. In the future there's been some talk about integrating the system-config-* tools into GnomeControlCenter. It's already in RHEL and Fedora, some screen shots: http://linux.softpedia.com/screenshots/Gnome-Control-Center_1.png http://linux.softpedia.com/screenshots/Gnome-Control-Center_2.png http://linux.softpedia.com/screenshots/Gnome-Control-Center_3.png On the other hand, something that's been a big adjustment - SELinux in redhat 5. It seems like none of the vendors out there support running under SELinux. For example, for both our monitoring product and backup solution I've had to craft custom SELinux policy exceptions. I don't really blame Redhat for this, but I'm pissed as all h*** at the vendors. Follow me on this as I descend into ranting for the rest of this post, or perhaps not, to preserve your sanity :-) I'm pretty keen on hearing more about this. While switching your system into Strict or MLS mode _will unquestionably break things_, leaving it in the stock Targeted mode shouldn't be to much of a hassle. What apps did you run into problems with? I'm not a Zed user, but I do manage a few Linux systems. On one, I like to symlink into an ISO image to get it mounted view autofs. The idea was to loop-mount the ISO image when I want to do an http install. Here is one example line from my /etc/auto.misc: fc5 -fstype=iso9660,ro,nosuid,nodev,noexec,loop :/var/local/mirrors/linux/Fedora/5/i386/ISO/FC-5-i386-DVD.iso I serve from a directory under /var/local/mirrors, and it had been my practice to symlink the install tree like this: /var/local/mirrors/linux/CentOS/5.1/os/i386 - /misc/C5 Unfortunately, I've not been able ti divine the magic incantation to get it mounted and accessible to Apache. The system's adequately isolated from the ungodly, but the only way I have to make this work is to turn selinux off, and this irks. I'll start a new thread to answer this question provide a detailed answer. I'm opposed to thread jacking this and turning it into a SELinux conversation, as I'm sure there may be more questions ;) The amount of packages installed is completely customizable. Don't install cups if you don't need it. I think the wish it to install an absolute minimum of packages. People have been asking for this for years. It's been available in both distributions for a large amount of time. I've been a user of RHEL since the mid 90s, and I recall the option being available then. I've only casually played with SLES, but I do recall them having a similar capability. For RHEL we define things in Package Groups. If you're using the GUI installer, you'll see a screen like this: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/x8664-multi-install-guide/figs/pkgselection/pkg-group.png In it you can select/deselect major package groups, such as GNOME, KDE, Server Tools, etc. Near the bottom is an option that says Minimal, which will *only* install the base packages needed for a working system. Screen shot @ http://www-128.ibm.com/developerworks/eserver/library/es-rhel-coexist/rh3.jpg For those of you *not* using the GUI install (i.e. kickstart), the package group is @Base. Note that in YUM you can also do a yum groupinstall and a yum groupremove. A fairly complete list of current package groups are: The discussions around yum-updated have been long internally to RHT. I don't know what the history is there, other than I'm in no position to change it. And I do agree with you on that point, especially for enterprise servers. My wife is a mere mortal Fedora user. She should
Making SELinux work (was: Re: Some observations regarding admining rhel v. sles on Z)
As promised, an answer to SELinux in a separate thread. On the other hand, something that's been a big adjustment - SELinux in redhat 5. It seems like none of the vendors out there support running under SELinux. For example, for both our monitoring product and backup solution I've had to craft custom SELinux policy exceptions. I don't really blame Redhat for this, but I'm pissed as all h*** at the vendors. Follow me on this as I descend into ranting for the rest of this post, or perhaps not, to preserve your sanity :-) I'm pretty keen on hearing more about this. While switching your system into Strict or MLS mode _will unquestionably break things_, leaving it in the stock Targeted mode shouldn't be to much of a hassle. What apps did you run into problems with? I'm not a Zed user, but I do manage a few Linux systems. On one, I like to symlink into an ISO image to get it mounted view autofs. The idea was to loop-mount the ISO image when I want to do an http install. Here is one example line from my /etc/auto.misc: fc5 -fstype=iso9660,ro,nosuid,nodev,noexec,loop :/var/local/mirrors/linux/Fedora/5/i386/ISO/FC-5-i386-DVD.iso I serve from a directory under /var/local/mirrors, and it had been my practice to symlink the install tree like this: /var/local/mirrors/linux/CentOS/5.1/os/i386 - /misc/C5 Unfortunately, I've not been able ti divine the magic incantation to get it mounted and accessible to Apache. The system's adequately isolated from the ungodly, but the only way I have to make this work is to turn selinux off, and this irks. I'll start a new thread to answer this question provide a detailed answer. I'm opposed to thread jacking this and turning it into a SELinux conversation, as I'm sure there may be more questions ;) This gets us into a little of MAC vs DAC theory. Under historical models privilege is granted based upon user/group settings. For example, say I have the following: 1) Apache is installed as user apache, group _system_ (yes, this actually is common!) 2) My DNS configuration file is owned by DNSUser, and _grouped to system_. *Problem: * If my web-facing Apache instance gets hacked, the attacker inherit Apaches group rights to system. My DNS configuration file is grouped to system. Apache gets hacked, and they now can potentially change my DNS configuration file. *Answer: *We introduce the concept of security labels via SELinux. Everything in Linux is ultimately a file -- from devices, processes, to actual data -- and thus we can create a new access model. With SELinux, our scenario looks more like: 1) Apache is installed as user apache, group system. Data that Apache should read is labeled as httpd_t 2) DNS is installed as user DNSUser, group system. Data that Bind should read is labeled as named_t Apache gets hacked, and the DNS configuration file has a different security label. Access will be denied, as Apache doesn't have access to named_t Under your setup, I'd suspect your /var/local directories get labeled as var_t, which Apache may not have access to. To troubleshoot this, we have a few options, in increasing complexity: 1) Put a blind fold on, wonder into a dark cave, and hope we don't fall. i.e. disable SELinux. Not ideal. 2) Disable SELinux protections _for the specific data type getting denied _3) Create your own policy I use Fedora on my laptop. Things in Fedora often break, causing me to fix them on the fly. In my case I have the most issues with VPN settings. (For those of you who were at my talk at zExpo, remember how my network didn't work?) All SELinux errors will go into /var/log/messages. A typical VPN error message for me is: /var/log/messages: type=SYSCALL msg=audit(1204719775.306:738): arch=4003 syscall=54 success=no exit=19 a0=4 a1=8933 a2=bfcec1bc a3=bfcec1bc items=0 ppid=3900 pid=5003 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm=ip exe=/sbin/ip subj=user_u:system_r:ifconfig_t:s0 key=(null) _*So, what do I know?*_ 1) AVC Event ID 738 2) syscall=54 (I'd have to google this) 3) root (or an application on its behalf) was running /sbin/ip 4) context = user_u:system_r:ifconfig_t:s0 _*What are my options?*_ *1) Disabling SELinux* Obviously not idea. It turns off *all* protections. *2) Disable SELinux Protetions _for the specific data type getting denied._ *A little known fact is that you can target which part of SELinux to turn off. I often have issues with my VPN configuration, and to fix them rapidly I turn off checking for the ifconfig_t. It's not ideal, but it *is* better than turning off SELinux as a whole. To do this, type # semanage permissive -a ifconfig_t *3) Create your own Policy*_* *_This isn't as hard as it used to be (NOTE: Use RHEL5!). We currently ship a tool called audit2allow, which will create the policy template for you. In *my* case I see that the audit ID is 738:
Re: Some observations regarding admining rhel v. sles on Z
On 11/24/08 12:04 PM, Shawn Wells [EMAIL PROTECTED] wrote: In the future there's been some talk about integrating the system-config-* tools into GnomeControlCenter. It's already in RHEL and Fedora, some screen shots: http://linux.softpedia.com/screenshots/Gnome-Control-Center_1.png http://linux.softpedia.com/screenshots/Gnome-Control-Center_2.png http://linux.softpedia.com/screenshots/Gnome-Control-Center_3.png If you do this, please make sure there is a text-only version. Many people don't install X at all on headless servers. -- 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: SLES 10 SP 2 - OSA-Express Setup Assistance
On 11/24/2008 at 12:38 PM, David Stuart [EMAIL PROTECTED] wrote: Hi Mark, No, I don't believe so. But I'm still within my trial period. I'll place a call. If you mean you're running evaluation software, that doesn't come with any support. If you mean the 30-day installation support that comes with Basic, then go for it. 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
Re: Some observations regarding admining rhel v. sles on Z
Patrick Spinler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shawn Wells wrote: Hi Patrick, I thought I'd take the chance to respond to this, publicly, since I haven't seen any other threads. ... *) Integration to the Z platform The zipl issues were fixed and will be released in RHEL 5.3, https://bugzilla.redhat.com/show_bug.cgi?id=381201. Brad Hinson (who many people on this list know) was the champion of getting this pushed through. Thanks Brad, and Shawn! Thanks to Brad on that one. I didn't play any role in it ;) A couple of other notes about s390 integration, since I didn't want to put everything in my first message: *) mkinitrd mkinitrd in SuSE is notably more convenient, in two ways. One s390 specific way, and one architecture neutral way: +) It automagically pulls the current list of activated DASD channel numbers, and includes those in the ramdisk image it builds for activation at next IPL. No forgetting to edit /etc/modules.conf when extending a machine with more DASD. Good idea. I opened a Feature Request for this @ https://enterprise.redhat.com/issue-tracker/?module=issuesaction=viewtid=242519 (IT 242519). We'll see what engineering says re: how hard this would be to implement. Since the code is already in SLES, it *might* just be a matter of taking it putting it through Red Hat QA. We'll see. +) It automagically builds a initrd for every installed kernel in /boot, unless given just a specific kernel by command line options. Not having mandatory options for mkinitrd is sweet. Submitted Red Hat Issue Tracker #242520 https://enterprise.redhat.com/issue-tracker/?module=issuesaction=viewtid=242520 *) Device management It's convenient and easy in YaST to, for example, bring a new DASD online, dasdfmt it, partition it, and add it to a volume group. But using system-config-lvm? Not so easy. In fact, the information it displays is outright incorrect. Enough so that I'm quite adverse to trying to use it and messing things up. On one machine, for example, it shows /dev/dasdc under the list of Uninitialized entities, despite the fact that /dev/dasdc1 is a active PVM in an active volume group. I can't comment on other device types, e.g. qeth devices, because we do those so infrequently in comparison. Actually, Red Hat IBM have been working on this one. IBM LTC 201690 Red Hat BugZilla 463184 (https://bugzilla.redhat.com/show_bug.cgi?id=463184) 1. Feature Overview: Feature Id: [201690] a. Name of Feature: Installer - FCP LUN discovery tool b. Feature Description This feature should exploit the functionality to discover the LUNs on the Storage System for a given FCP adapter and WWPN, integrating the LUNs discovered as a drop down list (combobox) in the SCSI configuration dialog, so that the customer does not have to manually give it. 3. Business Case These changes will improve the installation experience for customers by making the installation workflow more usable and efficient, which will result on an improvement of the customer satisfaction. Without this feature is the input of a 64bit value in Hex (=16 characters) not so so usable and can produce errors and frustration for the customer. Out of curiosity, where do you (and ultimately, everyone else on the list) turn to for this information? Are you familiar with Red Hat's Knowledge Base (http://kbase.redhat.com) and Novell's support center (http://www.novell.com/support/microsites/microsite.do)? Always a good one is the Linux documentation project: http://tldp.org/ I mostly use google. Sometimes google points out an article in kbase or Novell's support center. Sometimes I get a good hit on a blog or email list archive. Of course typing system-configtabtab at a terminal gives you a list of installed configuration tools, but you have to be taught to do that in the first place. I understand this, but I also think it's part of learning a new operating system. Just like when you get into a new car you must find the blinkers, head lights, seat adjust, etc. Similar, but a little different in each one. On the flip side, a real strength of AIX's SMIT and SMITTY administration tools compared to YaST is that they show you exactly what they are changing and what commands they're running. Would it really be so hard to throw a --show-action flag on the system-config toolchain, and a simple GUI front end on top of them? I don't see why it couldn't be. I'll look into this some more. In theory it'd be easy enough to send something through logger to /var/log/system-config-* or /var/log/messages. *) Another addition to my list, but one I didn't talk about in comparison was documentation. Here I have to comment that for new Redhat facilities the documentation is often missing or incomplete. For example, when RHEL 5 first hit I set up a test host to mess around with Xen virtualization. The RHEL 5 Virtualization manual was flat out incorrect in what the packaged management
Re: Some observations regarding admining rhel v. sles on Z
On 11/24/2008 at 1:14 PM, David Boyes [EMAIL PROTECTED] wrote: -snip- If you do this, please make sure there is a text-only version. Many people don't install X at all on headless servers. Pretty much by definition, GNOME Control Center is going to be GUI only. That was one of the things I appreciated in YaST when I was a customer. As ugly as it was, the ncurses version worked in any environment where the network was up. 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
Re: Some observations regarding admining rhel v. sles on Z
On 11/24/08 2:10 PM, Mark Post [EMAIL PROTECTED] wrote: On 11/24/2008 at 1:14 PM, David Boyes [EMAIL PROTECTED] wrote: -snip- If you do this, please make sure there is a text-only version. Many people don't install X at all on headless servers. Pretty much by definition, GNOME Control Center is going to be GUI only. That was one of the things I appreciated in YaST when I was a customer. As ugly as it was, the ncurses version worked in any environment where the network was up. My point exactly. A X-only UI is not an significant improvement. There needs to be a curses version as well as the X version. -- 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
SUSE 10 Installation Help
My boss came home from a tech conference with an evaluation copy of SUSE 10. I am trying to install it and I seem to be stuck. I have completed the install and IPLed the new system. There is a message on the console to logon and run the command /usr/lib/YaST2/startup/YaST2.ssh. I can connect via ssh, but I do not know the root password to logon. Apparently it is not the same as the temp ssh password that I setup on the installation system. Is there a default root password? Thanks for your help, Russell Jones ANPAC System Programmer -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Monday, November 24, 2008 1:10 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Some observations regarding admining rhel v. sles on Z On 11/24/2008 at 1:14 PM, David Boyes [EMAIL PROTECTED] wrote: -snip- If you do this, please make sure there is a text-only version. Many people don't install X at all on headless servers. Pretty much by definition, GNOME Control Center is going to be GUI only. That was one of the things I appreciated in YaST when I was a customer. As ugly as it was, the ncurses version worked in any environment where the network was up. 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
Re: SUSE 10 Installation Help
It will be the temporary password that you entered during the first part of the install. Make sure you have the proper case for the password. Jones, Russell wrote: My boss came home from a tech conference with an evaluation copy of SUSE 10. I am trying to install it and I seem to be stuck. I have completed the install and IPLed the new system. There is a message on the console to logon and run the command /usr/lib/YaST2/startup/YaST2.ssh. I can connect via ssh, but I do not know the root password to logon. Apparently it is not the same as the temp ssh password that I setup on the installation system. Is there a default root password? Thanks for your help, Russell Jones ANPAC System Programmer -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009 -- 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: SUSE 10 Installation Help
I am 99% sure of what I set the password to in the first part of the installation. I was able to logon via ssh for the first part of the install, but the password is not being accepted now. If I can't get the password to work, is my only option to start the install over from the beginning? Russell Jones ANPAC System Programmer -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Monday, November 24, 2008 1:48 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: SUSE 10 Installation Help It will be the temporary password that you entered during the first part of the install. Make sure you have the proper case for the password. Jones, Russell wrote: My boss came home from a tech conference with an evaluation copy of SUSE 10. I am trying to install it and I seem to be stuck. I have completed the install and IPLed the new system. There is a message on the console to logon and run the command /usr/lib/YaST2/startup/YaST2.ssh. I can connect via ssh, but I do not know the root password to logon. Apparently it is not the same as the temp ssh password that I setup on the installation system. Is there a default root password? Thanks for your help, Russell Jones ANPAC System Programmer -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009 -- 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: SUSE 10 Installation Help
Hello Russel, I don't know if you are connecting from a windows (putty) or linux PC (ssh or openssh) but yesterday I installed a system and connected from a linux machine. SSH from linux apparently sends the userid with it. So I had to issue ssh -l root 192.168.200.2 instead of just ssh 192.168.200.2 to force the root login. Once I used the -l option I was granted the root login and the password I supplied in the install was accepted. Regards, Berry. Jones, Russell schreef: I am 99% sure of what I set the password to in the first part of the installation. I was able to logon via ssh for the first part of the install, but the password is not being accepted now. If I can't get the password to work, is my only option to start the install over from the beginning? Russell Jones ANPAC System Programmer -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Monday, November 24, 2008 1:48 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: SUSE 10 Installation Help It will be the temporary password that you entered during the first part of the install. Make sure you have the proper case for the password. Jones, Russell wrote: My boss came home from a tech conference with an evaluation copy of SUSE 10. I am trying to install it and I seem to be stuck. I have completed the install and IPLed the new system. There is a message on the console to logon and run the command /usr/lib/YaST2/startup/YaST2.ssh. I can connect via ssh, but I do not know the root password to logon. Apparently it is not the same as the temp ssh password that I setup on the installation system. Is there a default root password? Thanks for your help, Russell Jones ANPAC System Programmer -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009 -- 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: Some observations regarding admining rhel v. sles on Z
David Boyes wrote: On 11/24/08 2:10 PM, Mark Post [EMAIL PROTECTED] wrote: On 11/24/2008 at 1:14 PM, David Boyes [EMAIL PROTECTED] wrote: -snip- If you do this, please make sure there is a text-only version. Many people don't install X at all on headless servers. Pretty much by definition, GNOME Control Center is going to be GUI only. That was one of the things I appreciated in YaST when I was a customer. As ugly as it was, the ncurses version worked in any environment where the network was up. My point exactly. A X-only UI is not an significant improvement. There needs to be a curses version as well as the X version. We also have to perform iterative development -- making things work together first, then presenting the GUI in differing ways. Should the Open Source community made tui/ncurses GUIs from the get go? Probably -- but we need to start somewhere. If you were to request priority to be given to tui-izing the system-config* tools, what would the order be? -- 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: Oracle DB's and Why??
We are running Oracle 10.2.0.3 on Linux System Z. These were new workloads for Business Intelligence, and Document Imaging. Rationale for choosing system Z was; Platform superiority over all others! Then; Cost avoidance - Performance - Scalability - Security - Native support for backup/restore/DR - Ability to diagnose end to end - Grid Integration (Agents z, Server Linux Intel) - Integration with Hipersockets for ZOS interfaces - Simplified administration - Ability to virtualize and clone new Oracle instances - Gerard C. Shockley Boston University [EMAIL PROTECTED] -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Brown, Christopher Sent: Friday, November 21, 2008 3:28 PM To: LINUX-390@VM.MARIST.EDU Subject: Oracle DB's and Why?? Hello List, If you are running Oracle Databases on zLinux, can you tell me why that choice was made?? Were the AIX or Wintel platforms considered?? Thanks, Chris IMPORTANT: This e-mail and any attachments may contain confidential, proprietary, and/or privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail, and destroy any copies. Any dissemination, copying, retention, printing, or use of this information by a person other than the intended recipient is unauthorized and may be illegal. Any opinions expressed in this e-mail are those of the author and may not reflect the views of the company. -- 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: Some observations regarding admining rhel v. sles on Z
Shawn Wells píše v Po 24. 11. 2008 v 17:18 -0500: David Boyes wrote: On 11/24/08 2:10 PM, Mark Post [EMAIL PROTECTED] wrote: On 11/24/2008 at 1:14 PM, David Boyes [EMAIL PROTECTED] wrote: -snip- If you do this, please make sure there is a text-only version. Many people don't install X at all on headless servers. Pretty much by definition, GNOME Control Center is going to be GUI only. That was one of the things I appreciated in YaST when I was a customer. As ugly as it was, the ncurses version worked in any environment where the network was up. My point exactly. A X-only UI is not an significant improvement. There needs to be a curses version as well as the X version. We also have to perform iterative development -- making things work together first, then presenting the GUI in differing ways. Should the Open Source community made tui/ncurses GUIs from the get go? Probably -- but we need to start somewhere. The system-config* tools are being divided onto the backend (worker) part and the frontend (GUI). So the TUI counterparts can concentrate on implementing the UI only. If you were to request priority to be given to tui-izing the system-config* tools, what would the order be? Dan -- Dan Horák Software Engineer, BaseOS Red Hat Czech s.r.o., Purkyňova 99, 612 45 Brno -- 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
