toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

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

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

13 Jun '00

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. http://now.netapp.com/NOW/knowledge/docs/olio/guides/53_troubleshooting/con… .shtml Assuming you are using a UNIX qtree (the default) then you have two options of how the NT users will interact with the UNIX style security. The first option is to use strict UNIX type security. Each NT user is mapped to a UNIX identity and vanilla UNIX type security is used. In this case option cifs.perm_check_use_gid should be set to ON. The second option is closer to the NT style of FAT security. If cifs.perm_check_use_gid is OFF, then everyone except the owner is considered a member of the "group". The main control on security is the share level ACL (just like NT). This is controlled by cifs access entries. We allow a further tuning of the ACL by also requiring any access be permitted by the group permissions on the file. The world permissions are not used by PCs (if everyone is permitted access by the share ACL, then world is a member of the "group"). The filer will appear to be a FAT file system to the PC clients. They will probably want to install Secure Share Access to allow them to control the security on files. SecureShare(tm) Access (176KB) SecureShare Access is a DLL for Win95 and Windows NT 4.0 which adds a page to the Properties... sheet for files which reside on NetApp filers. Double-clicking SSACCESS.EXE causes a self-extracting installer to run, installing the DLL and making the appropriate registry entries. The DLL can be uninstalled at any time by using the Add/Remove programs utility on the Control Panel. SecureShare Access is believed to work on Win98 and Windows NT 5.0, but has not been tested on these platforms and is not supported on them. http://now.netapp.com/NOW/tools/supported.shtml You may also wish to look at the following burt since that affects some of the fine points of UNIX style access. http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=21019 -----Original Message----- From: Elizabeth Schwartz [mailto:eschwart@genuity.net] Sent: Friday, June 09, 2000 12:55 PM To: Muhlestein, Mark Cc: eschwart(a)genuity.net; toasters(a)mathworks.com Subject: RE: Unix group permissiosn and NT access on a filer Thanks! IT sounds like what we need is a "cred-GID" am I reading this right? I want to give an NT user the right to access files from his NT box that members of his unix group can access on the Unix side, on a filer set to unix file perms At 11:21 AM 6/9/00 -0700, mark.muhlestein(a)netapp.com wrote: >This is controlled via the option cifs.perm_check_use_gid. See > >http://now.netapp.com/NOW/knowledge/docs/olio/guides/53_troubleshooting/faq >.shtm >l#anchor1392048 > >"My CIFS clients are seeing strange group access with UNIX-style security >files" > >Mark Muhlestein -- mmm(a)netapp.com > > > -----Original Message----- > > From: Elizabeth Schwartz [mailto:eschwart@genuity.net] > > Sent: Friday, June 09, 2000 8:19 AM > > To: toasters(a)mathworks.com > > Subject: Unix group permissiosn and NT access on a filer > > > > > > Please forgive any NT terminology mangling, I'm a Unix person: > > > > We've got a filer that is set up as a Unix filesystem (as opposed to > > multiprotocol.) > > Our NT users access their home directories as NT shares on > > this filer. > > Their NT login names match their Unix user id's. > > > > On the unix side, I created a group and made a > > group-writeable directory > > that is not readable to others. When the NT users log into our unix > > machine, they can write files in this directory. When they > > access this > > directory from the Unix side, only the owner can write files. > > > > Is this fixable? Without making dramatic changes to the > > filer? (I do have > > enough space to make a small extra partition if I really had to) > > -- > > Elizabeth Schwartz 781-262-6565 > > Unix System Administrator eschwart(a)bbnplanet.com > > Genuity, Inc > > -- Elizabeth Schwartz 781-262-6565 Unix System Administrator eschwart(a)bbnplanet.com Genuity, Inc

1 0

Jump to page:

2025

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