bengsig@oracle.nl (Bjorn Engsig) (11/13/90)
Article <32547@netnews.upenn.edu> by reilly@scotty.dccs.upenn.edu (G. Brendan Reilly) says: |This is in response to the neophyte who wants IBM to port |SMIT to other systems: I guess that somebody is me, since I've said that a few times in this newsgroup. I wouldn't actually concider myself a neophyte, on the contrary; I've been in Unix for 10 years, AIX for 3, and AIX 3.1 since January. And I still think that SMIT is a really good tool for system administration, and that making kernel extensions the way it is done in AIX 3.1 is much better than the 'oldfashioned' link/reboot. Mr. Reilly continued complaining about problems with SMIT. Well, I never said that IBM's software was bugfree, I have only commented that the _ideas_ in the software are good. And the best way to improve the quality of the IBM products is probably not to flame them here, but to struggle your way politely through their bureaucracy, (which I know can be hard, but it is doable). | |I stand with Steve - IBM made a major mistake redefining all |of the system management tools, This could be turning into a war, but I think IBM made major step ahead. |and they are full of bugs. 'Full' is a strong word, I would say they are not bugfree. |The last thing any system needs is buggy system managment tools. The first thing any system needs is easy-to-use system managment tools. Thanks, IBM, for doing what my signature suggests. -- Bjorn Engsig, E-mail: bengsig@oracle.com, bengsig@oracle.nl ORACLE Corporation Path: uunet!orcenl!bengsig "Stepping in others footsteps, doesn't bring you ahead"
dyer@spdcc.COM (Steve Dyer) (11/14/90)
This is a silly discussion. Let me clarify for Mr. Bjorn of Oracle
that I am not particularly anti-SMIT, anti-logical volumes, or anti-
kernel extensions, although I tend to agree with the guy from Penn that
SMIT is a better idea than its present realization. In fact, I didn't
mention any of these new features as objects of criticism. What IS
annoying was the apparent need of IBM to redo common ways of doing old
things (not new things) so that the 17 years of system management
skills are essentially useless. God forbid you should be doing
anything half-way complicated without all the manuals close by, and the
one you need (you know, the one which maps all the damn LED error
codes when the system crashes or doesn't reboot) is never around. Feh.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edujsalter@slo (11/15/90)
In article <4871@spdcc.SPDCC.COM> dyer@ursa-major.spdcc.com (Steve Dyer) writes: >What IS >annoying was the apparent need of IBM to redo common ways of doing old >things (not new things) so that the 17 years of system management >skills are essentially useless. This is not a new argument/comment. Either inside IBM AWD or outside IBM. If you don't like it and can make a convincing argument to the powers-that-be, please do so. In the meantime, I'm waiting for what OSF's DME is going to do. Now, THAT should be interesting. >Steve Dyer >dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer >dyer@arktouros.mit.edu, dyer@hstbme.mit.edu jim/jsalter IBM AWD, Palo Alto T465/(415)855-4427 VNET: JSALTER at AUSVMQ Internet: jsalter@slo.awdpa.ibm.com UUCP: ..!uunet!ibmsupt!jsalter PS/2 it, or DIE! :-) The ramblings above have nothing to do with Big Blue.
bengsig@oracle.nl (Bjorn Engsig) (01/14/91)
In a number of articles, the ODM, it's editor odme, and SMIT are discussed, and in article <4740@awdprime.UUCP> jerry@heyman.austin.ibm.com (Jerry Heyman) says: | |When I said 'most' configuration could still be done in stanza files (and I |gave the example of inet.conf) [ ... ]. If you use |SMIT and ODM for all your configuration information, then you should be ok. |Some people might not want to have all their information in an ODM database, |so we have given the option of starting some of the commands (again I'll use |inetd) by telling it NOT to use ODM and to use the stanza files. | |A thing to note when using smit. It always modifies the appropriate odm |database, but doesn't update a stanza file that has the same information in |it. This is a shortcoming of the tool and is being addressed. Yes, this is a shortcoming, in my opinion a somewhat different one, though; being in the database world has taught my one very important thing: NEVER, EVER keep redundant information, and I guess this is actually what confuses people, and makes us uncertain weather to use SMIT or the other tools. What happens if I create a user by editing /etc/passwd, mkdir, chown, create .profile, and run passwd? What happens if I nfs mount a directory using /etc/mount? As these examples show, it is often hard for us to make sure that all the sysadm information is consistent. If your answer to this is, 'always use SMIT', then: How do I use SMIT to increase the maximum number of processes per user? (Done by 'chdev -l sys0 -a maxuproc=200') -- Bjorn Engsig, E-mail: bengsig@oracle.com, bengsig@oracle.nl ORACLE Corporation Path: uunet!orcenl!bengsig "Stepping in others footsteps, doesn't bring you ahead"
timborn@cbnewsd.att.com (timothy.d.born) (01/15/91)
In article <1174@nlsun1.oracle.nl>, bengsig@oracle.nl (Bjorn Engsig) writes: > In a number of articles, the ODM, it's editor odme, and SMIT are discussed, and > in article <4740@awdprime.UUCP> jerry@heyman.austin.ibm.com (Jerry Heyman) says: > | > |A thing to note when using smit. It always modifies the appropriate odm > |database, but doesn't update a stanza file that has the same information in > |it. This is a shortcoming of the tool and is being addressed. > Yes, this is a shortcoming, in my opinion a somewhat different one, though; > being in the database world has taught my one very important thing: NEVER, > EVER keep redundant information, and I guess this is actually what confuses > people, and makes us uncertain weather to use SMIT or the other tools. What > happens if I create a user by editing /etc/passwd, mkdir, chown, create > .profile, and run passwd? What happens if I nfs mount a directory using > /etc/mount? As these examples show, it is often hard for us to make sure > that all the sysadm information is consistent. If your answer to this is, > 'always use SMIT', then: How do I use SMIT to increase the maximum number of > processes per user? (Done by 'chdev -l sys0 -a maxuproc=200') > -- > Bjorn Engsig, E-mail: bengsig@oracle.com, bengsig@oracle.nl > ORACLE Corporation Path: uunet!orcenl!bengsig > > "Stepping in others footsteps, doesn't bring you ahead" Bjorn, I have to agree with you. The redundant stuff burns us every time. As for SMIT modifying ODM, I believe it, but I have been assured repeatedly by my IBM reps that SMIT is not doing things behind my back. To quote from bos/README (3003; pretty much the same info was in 3002 README): "Please notice that SMIT is a read-only shell; by itself, it alters nothing on your system. Instead it executes commands that do all the work. Therefore execution of commands from SMIT gives the same results as execution from the command line." So which is right? SMIT does or does not play with ODM? Speaking of redundant, did anyone else notice that you have to assign your node name TWICE in order for it to stick? uuname -s and hostname -S must both be run, otherwise you have a schizo system. -tim t.born@att.com
bengsig@oracle.nl (Bjorn Engsig) (01/16/91)
In article <1174@nlsun1.oracle.nl>, I wrote: | being in the database world has taught my one very important thing: NEVER, | EVER keep redundant information, and I guess this is actually what confuses | people, and makes us uncertain weather to use SMIT or the other tools. | | Article <1991Jan15.143208.25540@cbnewsd.att.com> by timborn@cbnewsd.att.com (timothy.d.born) says: | |"Please notice that SMIT is a read-only shell; by itself, it alters nothing |on your system. Instead it executes commands that do all the work. Sure, I might not have made myself clear. To the casual user it looks like SMIT does al the work for you, and what worries me is that I don't know if e.g. the command that smit calls to say create a user also does things to the ODM, or if the system status will be the same if I vipw, mkdir, etc. by hand. |So which is right? SMIT does or does not play with ODM? Not per se, but the commands it issues does play with the ODM. And speaking about redundancy: "Completely and totally remove all repetitive redundancy" -- Bjorn Engsig, E-mail: bengsig@oracle.com, bengsig@oracle.nl ORACLE Corporation Path: uunet!orcenl!bengsig "Stepping in others footsteps, doesn't bring you ahead"
jerry@heyman.austin.ibm.com (Jerry Heyman) (01/17/91)
In article <1991Jan15.143208.25540@cbnewsd.att.com> timborn@cbnewsd.att.com (timothy.d.born) writes: >In article <1174@nlsun1.oracle.nl>, bengsig@oracle.nl (Bjorn Engsig) writes: >> In a number of articles, the ODM, it's editor odme, and SMIT are discussed, and >> in article <4740@awdprime.UUCP> jerry@heyman.austin.ibm.com (Jerry Heyman) says: >> | [... my comments about smit and modifying the odm ...] >> >> Bjorn's comments about redundent information. > > >Bjorn, I have to agree with you. The redundant stuff burns us every time. > >As for SMIT modifying ODM, I believe it, but I have been assured repeatedly >by my IBM reps that SMIT is not doing things behind my back. To quote >from bos/README (3003; pretty much the same info was in 3002 README): > >"Please notice that SMIT is a read-only shell; by itself, it alters nothing >on your system. Instead it executes commands that do all the work. Therefore >execution of commands from SMIT gives the same results as execution from >the command line." > >So which is right? SMIT does or does not play with ODM? Mea culpa. My apologies for the misunderstandings with SMIT and ODM. The IBM rep is correct when they say that SMIT DOES NOT modify the odm databases. SMIT is a front end that build commands (the same ones that can be executed from the command line) and executes them for you. SMIT itself DOES NO modifications. The various commands that are invoked do the modifications. Since the modifications take place BECAUSE smit executes these commands, I usually say that SMIT modifies the ODM databases. I can see where the confusion occurs and for that I apologize. Again, think of SMIT as a big shell script that invokes other shell scripts to build the appropriate command. When all the pertinent information is added by the user, then the appropriate AIX command is issued and executed. SMIT is a command BUILDER. Sorry for the confusion. > >-tim >t.born@att.com jerry -- Jerry Heyman IBM T-R: jerry@heyman.austin.ibm.com AWD Tools Development VNET : HEYMAN at AUSVMQ AWD Austin T/L : 793-3962 *** All opinions expressed are exactly that - my opinions and NOT IBM's
jfh@greenber.austin.ibm.com (John F Haugh II) (01/17/91)
In article <1991Jan15.143208.25540@cbnewsd.att.com> timborn@cbnewsd.att.com (timothy.d.born) writes: >As for SMIT modifying ODM, I believe it, but I have been assured repeatedly >by my IBM reps that SMIT is not doing things behind my back. To quote >from bos/README (3003; pretty much the same info was in 3002 README): The SMIT command builds regular commands which it then executes. To see what SMIT is going to do to your system, look at the smit.log and smit.script files, or press the <F6> key (it's marked "Command" or some such). This will let you see everything that SMIT is doing. >So which is right? SMIT does or does not play with ODM? All that SMIT does with respect to ODM is get the dialogs from there. In /etc/objrepos there are several ODM classes which begin with "sm". Those are the ODM files which contain SMIT dialogs. If you remove the part of the name after "." you can use ODME to break^H^H^H^H^Hexamine the dialogs. -- John F. Haugh II | I've Been Moved | MaBellNet: (512) 838-4340 SneakerNet: 809/1D064 | AGAIN ! | VNET: LCCB386 at AUSVMQ BangNet: ..!cs.utexas.edu!ibmchs!auschs!snowball.austin.ibm.com!jfh (e-i-e-i-o)