toasters June 2000

toasters@lists.teaparty.net

121 participants
153 discussions

RE: Lost password
by jeff.mohler＠netapp.com 14 Jun '00

14 Jun '00

There are however, some commands that dont work via rsh. I dont have a list handy, but they do exist. -----Original Message----- From: Jay Orr [mailto:orrjl@stl.nexen.com] Sent: Tuesday, June 13, 2000 2:02 PM To: TTSG Cc: Mohler, Jeff; gustavo(a)cpqd.com.br; toasters(a)mathworks.com Subject: Re: Lost password Nope! Just have to have the root access - you can use rsh to do any command from a remote machine. You can't do a straight rsh to get a shell on a filer, but you can do rsh <filer> <command> as root on a box that has root permissions to the filer... I just discovered it the other day.... On Tue, 13 Jun 2000, TTSG wrote: > > > > If all you wish to do is halt it...type halt. > > > > You can telnet to it, rsh to it, use Filerview... > > > I would imagine all of these need a password to log in, > which the user doesn't have.... Right? > > Tuc/TTSG > > -----Original Message----- > > From: TTSG [mailto:ttsg@ttsg.com] > > Sent: Tuesday, June 13, 2000 7:26 AM > > To: gustavo(a)cpqd.com.br > > Cc: toasters(a)mathworks.com > > Subject: Re: Lost password > > > > > > > > > > Hi, > > > > > > Please, forgive me if this is in some FAQ but I couldn't find any. > > > (Could you point me to it?) > > > > > > I've lost the root password of our filer. I've read in the SA Guide > > > that I can change it by booting from a diskete. However, the filer is > > > up and running. How can I reboot it in a safe manner having no access > > > to its command line (short of powering it down)? > > > > > **THIS IS TOTALLY UNTESTED** > > > > I would think if you failed a drive, the system would bring itself > > down cleanly after X hours. > > > > Tuc/TTSG > > > > ----------- Jay Orr Systems Administrator Fujitsu Nexion Inc. St. Louis, MO _______________________________________________ Dl-toasters mailing list Dl-toasters(a)netapp.com http://mailhost.corp.netapp.com/mailman/listinfo/dl-toasters

3 4

RE: Lost password
by jeff.mohler＠netapp.com 13 Jun '00

13 Jun '00

If all you wish to do is halt it...type halt. You can telnet to it, rsh to it, use Filerview... -----Original Message----- From: TTSG [mailto:ttsg@ttsg.com] Sent: Tuesday, June 13, 2000 7:26 AM To: gustavo(a)cpqd.com.br Cc: toasters(a)mathworks.com Subject: Re: Lost password > > Hi, > > Please, forgive me if this is in some FAQ but I couldn't find any. > (Could you point me to it?) > > I've lost the root password of our filer. I've read in the SA Guide > that I can change it by booting from a diskete. However, the filer is > up and running. How can I reboot it in a safe manner having no access > to its command line (short of powering it down)? > **THIS IS TOTALLY UNTESTED** I would think if you failed a drive, the system would bring itself down cleanly after X hours. Tuc/TTSG

3 2

RE: Lost password
by jeff.mohler＠netapp.com 13 Jun '00

13 Jun '00

Of course..I was just answering the 'safe shutdown' issue. Recovering a lost passwd will require console access however. -----Original Message----- From: TTSG [mailto:ttsg@ttsg.com] Sent: Tuesday, June 13, 2000 8:57 AM To: Mohler, Jeff Cc: ttsg(a)ttsg.com; gustavo(a)cpqd.com.br; toasters(a)mathworks.com Subject: Re: Lost password > > If all you wish to do is halt it...type halt. > > You can telnet to it, rsh to it, use Filerview... > I would imagine all of these need a password to log in, which the user doesn't have.... Right? Tuc/TTSG > -----Original Message----- > From: TTSG [mailto:ttsg@ttsg.com] > Sent: Tuesday, June 13, 2000 7:26 AM > To: gustavo(a)cpqd.com.br > Cc: toasters(a)mathworks.com > Subject: Re: Lost password > > > > > > Hi, > > > > Please, forgive me if this is in some FAQ but I couldn't find any. > > (Could you point me to it?) > > > > I've lost the root password of our filer. I've read in the SA Guide > > that I can change it by booting from a diskete. However, the filer is > > up and running. How can I reboot it in a safe manner having no access > > to its command line (short of powering it down)? > > > **THIS IS TOTALLY UNTESTED** > > I would think if you failed a drive, the system would bring itself > down cleanly after X hours. > > Tuc/TTSG >

1 0

Fw: Your message to Dl-toasters awaits moderator approval
by Bruce Sterling Woodcock 13 Jun '00

13 Jun '00

Has anyone else gotten a message along these lines? Bruce ----- Original Message ----- From: <dl-toasters-admin(a)netapp.com> To: <sirbruce(a)ix.netcom.com> Sent: Tuesday, June 13, 2000 1:06 PM Subject: Your message to Dl-toasters awaits moderator approval > Your mail to 'Dl-toasters' with the subject > > Re: Lost password > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Message has implicit destination > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision.

2 1

RE: Unix group permission and NT access on a filer
by mark.muhlestein＠netapp.com 13 Jun '00

13 Jun '00

For the release you are running, it is possible to get the group permission checking you want by doing a "cifs terminate" then "cifs setup", and specifying that you want to "enforce UNIX semantics" when asked that setup question. However, there are a lot of good reasons to upgrade to 5.3x, and not just for CIFS-related issues. The links we gave before describe the 5.3 and later security model, and answer your questions. Briefly, in the situation you described, the files would continue to use UNIX-style permissions, since you did not include a step of having the CIFS clients setting an ACL (which sets NTFS-style permissions). See http://now.netapp.com/NOW/knowledge/docs/olio/guides/53_troubleshooting/ind… tml particularly the "Basic Concepts" section. See also http://now.netapp.com/NOW/knowledge/docs/olio/guides/53_troubleshooting/glo… .shtml#anchor1670777 which describes inherited security. Mark Muhlestein -- mmm(a)netapp.com > -----Original Message----- > From: Elizabeth Schwartz [mailto:eschwart@genuity.net] > Sent: Tuesday, June 13, 2000 9:59 AM > To: Hawley, Rob; mstjohn(a)genuity.net > Cc: eschwart(a)genuity.net; Muhlestein, Mark; toasters(a)mathworks.com > Subject: RE: Unix group permission and NT access on a filer > > > Thanks! > We're running 5.2.3P1 > > I've been talking to the filer admin about upgrading. It > sounds like the > immediate short-term fix to our problem might be to create a small > multiprotocol qtree while we evaluate whether to upgrade the > OS and/or > change the main qtrees. > > We need to make sure that we understand all the security > implications of > changing a qtree from unix to multiprotocol. > > Do you have anything that shows how the filer stores > permission, whatever > the filer equivalent of an inode is? (qnode? Wnode?) We were > trying to > whiteboard how the permissions work. Specifically: > > 1) I start with a Unix qtree on the filer > 2) User directory is created with unix permissions set to 755 > 3) We then change the qtree from unix to multiprotocol > 4) User accesses his directory as a CIFS share > 5) User creates a subdirectory and files under his home > > What will the permissions be on those files? 755? Will they > have anything > in their NT ACL's? > > I am under the impression that the filer stores permissions in some > "neutral" format which it translates to Unix permission bits > or NT ACL's, > PLUS has some extra storage for NT ACL's - is that how it works? > > Also, What happens if you create a multiprotocol file system and then > change it later to unix? Is the additional ACL information a) > translated, > b) deleted, c) stored but not used (so that if you changed it back to > multiprotocol again it might still be there?) > > thanks for any pictures > Betsy > > > At 07:06 AM 6/13/00 -0700, rob.hawley(a)netapp.com wrote: > >What version of the filer are you running? Is it 5.3 or later? > > > >The filer has always supported multiprotocol access to > files. With 5.3 we > >have > >completed our security model that is described in the > following paper. > > -- > Elizabeth Schwartz 781-262-6565 > Unix System Administrator eschwart(a)bbnplanet.com > Genuity, Inc >

1 0

question about shuffling disk drives around
by David H. Brierley 13 Jun '00

13 Jun '00

I have a situation where I need to replace one of the shelves in an F740 and I want to make sure that what I am planning to do will work ok. I am replacing the shelf because it has some kind of strange fault that causes the second power supply to immediately fail upon power up. I called it in to tech support and after trying a couple of things they ended up shipping me a replacement shelf. Unfortunately, the shelf has already been brought online because the initial failure appeared to be simply a bad power supply and I knew I would get a replacement within a day or so. The machine in question is heavily used and the project does not want me to take the machine down for any longer than is required. What I thought I would do is to shut down the machine and move all of the drives from the bad shelf to open slots on the other shelves (none of the shelves are full yet). I can then remove the bad shelf from the cabinet and install the replacement shelf, this time being careful to do a power up test before connecting the shelf to the filer. Once the new shelf is physically installed in the cabinet I can then shut down the filer, move the drives back to the new shelf, and reboot again. My understanding of the way the filer works tells me that this plan will work but I just wanted to get some feedback before attempting it. The alternative would be to shut down the filer and keep it down for an extended period while the bad shelf is removed and the new shelf is installed but obviously that would involve more down time and I am trying to avoid down time. -- David H. Brierley Raytheon Electronic Systems, Naval & Maritime Integrated Systems Engineering Technology, Operating Systems Support Group

1 0

DLT Problems
by Tom Arlington 13 Jun '00

13 Jun '00

Has anybody seen this ? There's something wrong with the tape drive and/or its configuration on our new Netapp box; the unload-reload command that's supposed to eject the tape and load the next one doesn't seem to work: iron> mt -f urst0a offline Tape device (0b.4) unload/reload failed - please check drive. mt: close of tape urst0a failed The tape ejects from the "DLT1" drive, but doesn't get replaced in the magazine and the next tape doesn't get loaded. This command works properly on our F540s with the smaller 10-tape Overland tape robots. I've talked with both Netapp and Overland and each company blamed the other one. I'm inclined to believe that it's something that I haven't configured properly on the tape drive, but the documentation is less than wonderful about explaining how to configure the auto-advance stuff. I have tried rebooting the tape drive and the netapp box to no avail. Any thoughts? Thanks!

2 1

RE: Unix group permission and NT access on a filer
by Elizabeth Schwartz 13 Jun '00

13 Jun '00

Thanks! We're running 5.2.3P1 I've been talking to the filer admin about upgrading. It sounds like the immediate short-term fix to our problem might be to create a small multiprotocol qtree while we evaluate whether to upgrade the OS and/or change the main qtrees. We need to make sure that we understand all the security implications of changing a qtree from unix to multiprotocol. Do you have anything that shows how the filer stores permission, whatever the filer equivalent of an inode is? (qnode? Wnode?) We were trying to whiteboard how the permissions work. Specifically: 1) I start with a Unix qtree on the filer 2) User directory is created with unix permissions set to 755 3) We then change the qtree from unix to multiprotocol 4) User accesses his directory as a CIFS share 5) User creates a subdirectory and files under his home What will the permissions be on those files? 755? Will they have anything in their NT ACL's? I am under the impression that the filer stores permissions in some "neutral" format which it translates to Unix permission bits or NT ACL's, PLUS has some extra storage for NT ACL's - is that how it works? Also, What happens if you create a multiprotocol file system and then change it later to unix? Is the additional ACL information a) translated, b) deleted, c) stored but not used (so that if you changed it back to multiprotocol again it might still be there?) thanks for any pictures Betsy At 07:06 AM 6/13/00 -0700, rob.hawley(a)netapp.com wrote: >What version of the filer are you running? Is it 5.3 or later? > >The filer has always supported multiprotocol access to files. With 5.3 we >have >completed our security model that is described in the following paper. -- Elizabeth Schwartz 781-262-6565 Unix System Administrator eschwart(a)bbnplanet.com Genuity, Inc

1 0

Sincere apology for the F330 SPAM
by ScottUCE＠aol.com 13 Jun '00

13 Jun '00

I was naive to not expect a hue and cry from the toasters group re: the message I sent re: the F330 equipment and not recognizing it to be the SPAM that, in hindsight, I guess that it was. I offer my sincere apology to the group. Scott Fischmann Union Computer Exchange, Inc.

1 0

RE: Did anyone else get this?
by Hackett, Roger 13 Jun '00

13 Jun '00

Yes, I got three bounced messages this weekend from autosupport(a)netapp.com. Roger Hackett Minerals Management Service > -----Original Message----- > From: Tuc [mailto:ttsg@ttsg.com] > Sent: Sunday, June 11, 2000 7:01 PM > To: toasters(a)mathworks.com > Subject: Did anyone else get this? > > > From daemon Sun Jun 11 20:59:42 2000 > Received: from localhost (localhost) > by heimdall.ttsg.com (8.9.3/8.9.3) with internal id UAA07790; > Sun, 11 Jun 2000 20:59:42 -0400 (EDT) > Date: Sun, 11 Jun 2000 20:59:42 -0400 (EDT) > From: Mail Delivery Subsystem <MAILER-DAEMON(a)heimdall.ttsg.com> > Message-Id: <200006120059.UAA07790(a)heimdall.ttsg.com> > To: ttsg(a)ttsg.com > Subject: Returned mail: User unknown > Auto-Submitted: auto-generated (failure) > Status: OR > Hi, > > Did anyone else get this? > > Forwarded message: > > From MAILER-DAEMON(a)valhalla.ttsg.com Sun Jun 11 20:48:27 2000 > > Message-Id: <200006120046.UAA05395(a)gevjon.ttsg.com> > > Date: 12 Jun 2000 00:09:16 -0000 > > From: MAILER-DAEMON(a)mx01.netapp.com > > To: XXXXXXX(a)ttsg.com > > Subject: failure notice > > > > Hi. This is the qmail-send program at mx01.netapp.com. > > I'm afraid I wasn't able to deliver your message to the > following addresses. > > This is a permanent error; I've given up. Sorry it didn't work out. > > > > <autosupport(a)netapp.com>: > > Sorry, I couldn't find any host named 10.10.20.91. (#5.1.2) > > > > --- Below this line is a copy of the message. > > > > Return-Path: <XXXXXXX(a)ttsg.com> > > Received: (qmail 20179 invoked from network); 11 Jun 2000 > 22:57:06 -0000 > > Received: from inbound.sys.gtei.net (HELO > burlma1-smrly1.gtei.net) (4.2.35.14) > > by mx01.dmz.netapp.com with SMTP; 11 Jun 2000 22:57:06 -0000 > > Received: from XXXXXXX.ttsg.com (XXXXXXX.ttsg.com [1.2.3.31]) > > by burlma1-smrly1.gtei.net (Postfix) with ESMTP id 9DB6F4791 > > for <autosupport(a)netapp.com>; Sun, 11 Jun 2000 04:01:24 > +0000 (GMT) > > Received: from XXXXXXXXXX (XXXXXXXXXX.ttsg.com [1.2.7.121]) > > by XXXXXXXX.ttsg.com (8.9.0/8.9.0) with SMTP id AAA06968; > > Sun, 11 Jun 2000 00:00:05 -0400 (EDT) > > From: XXXXXXXX(a)ttsg.com > > Message-Id: <200006110400.AAA06968(a)XXXXXXXX.ttsg.com> > > To: autosupport(a)netapp.com, ttsg(a)ttsg.com > > Date: Sun, 11 Jun 2000 00:00:09 -0400 > > Subject: System Notification from XXXXXXXXXX (WEEKLY_LOG) > > > > GENERATED_ON=Sun Jun 11 00:00:09 EDT 2000 > > VERSION=NetApp Release 5.3.4R3P2: Thu Feb 24 11:41:46 PST 2000 > > SYSTEM_ID=XXXXXXXXXX > > HOSTNAME=XXXXXXXXXX > > Console is using unspecified character set > > > (etc) > > Tuc/TTSG > > >

3 2

← Newer
1
...
6
7
8
9
10
11
12
...
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters June 2000