Fora do escritório!
Estarei ausente do escritório a partir de 13/09/2004 e não retornarei até 17/09/2004. Estarei ausente duratne este período. Por favor, entre em contato com Antonio Gouvea, Claudio Marcon. tel: 11 6847-9903 atenciosamente, R.H.O. -- 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: Shared /usr
The maintenance is what would get me. We will have a customised set of packages for each installation because each linux install will have a different task. For our setup the maintenance overhead alone seems like enough to keep me from exploring it too much. Besides, you make it sound so fun >>> [EMAIL PROTECTED] 9/13/2004 12:11:14 PM >>> > I have a question about sharing /usr with multiple vm guests. Is this a > recommended acrchitecture? Are there any benefits to doing this other > than saving space. It seems to me this could be problematic when > applying fixes from yast. I welcome any input on this subject. I do this all the time (both PC class and mainframe class Linux). On the mainframe, you get some storage constraint relief which is theoretically important because you might be running thousands of Linux instances. In any case, you get tremendous installation and maint relief, with some substantial caveats. Any time you have shared filesystem storage (shared disks) and you then perform an installation or upgrade, there will be some pieces that fall into the shared storage and some that fall outside of the shared areas. Bringing these into sanity, between the "master" where you did the maint and the "slaves" (or ... give me a better term) :-S which access that shared storage, is a pain. You can re-run RPM on the sharers (the "slaves"), and you'll get a bazillion errors. You can probably ignore most of the errors. But are you really sure? Besides, it's inelegant. And what about customizations? You might need to distribute your own special config of whatever you installed or upgraded. Re-running RPM on all your sharers would probably not get your custom config kicked out to them. RPM does not deal with read-only volumes. IT WOULD BE NICE if it could/would check the file to be installed (into a R/O directory) and IFF the file to be placed there matches a file already there, ignore the fact that he (RPM) cannot write the file he wants to write. It's already there! Right? But if you can put up with stuff like this, then I recommend sharing /usr (and /opt). No sarcasm here: I really run this way all the time. It's great! -- 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 Linux/390 asm-s390 Include files?
On 08/13/2003, Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
>How unfortunate. Well, it's Gerhards patch then:
>
>--- linux-2.4.19/include/asm-s390/ptrace.h.bak Mon Mar 17 19:59:32 2003
>+++ linux-2.4.19/include/asm-s390/ptrace.h Mon Mar 17 20:00:05 2003
>@@ -129,7 +129,9 @@
> {
>float f;
>double d;
>+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> __u64 ui;
>+#endif
>struct
>{
>__u32 hi;
>
>I wonder if there are any other __u64 types in the kernel headers that
could
>break strict ansi compiles. There is one in lowcore.h which could cause
>trouble.
It looks like there might be. When running ./configure for the kdebase
package, it checks for the presence and usability of linux/raw.h. It gets
this error:
configure:41322: checking linux/raw.h usability
configure:41334: s390-slackware-linux-gcc -c -ansi -W -Wall
-Wchar-subscripts -Wshadow -Wpointer-arith -Wmissing-prototypes
-Wwrite-strings -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DNDEBUG -O2 -O2 -Wformat
-security -Wmissing-format-attribute -DQT_THREAD_SUPPORT -D_REENTRANT
conftest.c >&5
In file included from conftest.c:161:
/usr/include/linux/raw.h:12: error: parse error before "__u64"
The contents of the file are:
/usr/include/linux/raw.h
#ifndef __LINUX_RAW_H
#define __LINUX_RAW_H
#include
#define RAW_SETBIND _IO( 0xac, 0 )
#define RAW_GETBIND _IO( 0xac, 1 )
struct raw_config_request
{
int raw_minor;
__u64 block_major;
__u64 block_minor;
};
#endif /* __LINUX_RAW_H */
This gets copied from /usr/src/linux-2.4.26/include/linux/raw.h, so it is in
the generic Linux part of the tree, and not 390-specific. Any ideas on
whether this should be fixed or not?
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: Shared /usr
> I have a question about sharing /usr with multiple vm guests. Is this a > recommended acrchitecture? Are there any benefits to doing this other > than saving space. It seems to me this could be problematic when > applying fixes from yast. I welcome any input on this subject. I do this all the time (both PC class and mainframe class Linux). On the mainframe, you get some storage constraint relief which is theoretically important because you might be running thousands of Linux instances. In any case, you get tremendous installation and maint relief, with some substantial caveats. Any time you have shared filesystem storage (shared disks) and you then perform an installation or upgrade, there will be some pieces that fall into the shared storage and some that fall outside of the shared areas. Bringing these into sanity, between the "master" where you did the maint and the "slaves" (or ... give me a better term) :-S which access that shared storage, is a pain. You can re-run RPM on the sharers (the "slaves"), and you'll get a bazillion errors. You can probably ignore most of the errors. But are you really sure? Besides, it's inelegant. And what about customizations? You might need to distribute your own special config of whatever you installed or upgraded. Re-running RPM on all your sharers would probably not get your custom config kicked out to them. RPM does not deal with read-only volumes. IT WOULD BE NICE if it could/would check the file to be installed (into a R/O directory) and IFF the file to be placed there matches a file already there, ignore the fact that he (RPM) cannot write the file he wants to write. It's already there! Right? But if you can put up with stuff like this, then I recommend sharing /usr (and /opt). No sarcasm here: I really run this way all the time. It's great! -- 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: Shared /usr
Thanks for the reply. This info will help me make the decision on wether to use shared /usr or not. -Doug >>> [EMAIL PROTECTED] 9/10/2004 3:16:33 PM >>> This is one possible architecture. Whether it's recommended or not depends on why you want to do it. The advantages are 1) saving disk space. Depending on how expensive dasd is in your organization, this can be considerable. 2) Allowing minidisk cacheing to take place, reducing the number of physical I/O's and speeding up response. 3) keeping your users from installing programs or making modifications on their own and then calling you at three in the morning when their server goes down. then you find out after two hours of work that the problem is some modification they made. 4) Creating a "standard" version of Linux that is easily deployable. The disadvantages are: 1) Service is much more difficult. You have to install updates on a test server, then compare before and after with tripwire to see what files were updated on /usr and which were not. You have to route the non-/usr files around then swap /usr disks and reboot. You end up having almost as many /usr disks with different versions on them than you would have if everybody just had their own disk. I've got 38 servers and 6 different shared /usr disks, not to mention 4 or 5 servers with non-shared /usr. 2) you have altercations with users who want to write to the /usr disk. Usually you can get around it by loop-mounting a subdirectory in /home over a /usr subdirectory. Installing WebSphere with a read-only /usr is virtually impossible, as are other program products. I'd say if all of your linux servers are essentially identical, shared /usr makes a lot of sense. If they are all configured differently, question it. We've been using shared /usr for about three years. We are considering going to individual read-write /usr areas with SLES9, just for the ease in maintenance. Disk is cheap here. We bill our customers only $6.14 per gigabyte per month for 3390 dasd storage. A full-pack 3390-3 for /usr is about 80% full and is about 2.2GB. Check out my presentation at SHARE on this topic at http://linuxvm.org/present/SHARE101/S9343GWa.pdf So one elephant says to another, "You'll never believe what happened last night. I was trying on Groucho Marx's pajamas--and he shot me!" Gordon Wolfe, Ph.D. (425)865-5940 VM Technical Services, The Boeing Company > -- > From: Doug Griswold > Reply To: Linux on 390 Port > Sent: Friday, September 10, 2004 11:24 AM > To: [EMAIL PROTECTED] > Subject: Shared /usr > > I have a question about sharing /usr with multiple vm guests. Is this a > recommended acrchitecture? Are there any benefits to doing this other > than saving space. It seems to me this could be problematic when > applying fixes from yast. I welcome any input on this subject. > > > > Thanks, > Doug > > -- > 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: SLES7 SILO problem...
> On Sat, 2004-09-11 at 19:35, Lee Stewart wrote: > > Yes, it's downlevel, but it was the last "free" (publicly > downloadable) > > version. And this client wanted something for free > evaluation only > > Lee SuSE 7.0 and SLES 7 are two very different things. There was only a beta of SLES 7 downloadable, and it had problems (IMHO) that would significantly affect evaluation. I don't think the production SLES 7 was downloadable (or if it is, I'm sure that SuSE (and others) would like to know about it). SuSE 7.0 is so old that it (like the Marist drops) is unlikely to be able to run anything modern. Debian or Fedora would be a lot more representative of a modern version, and at least you can get support for them. -- db -- 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
