toasters

toasters@lists.teaparty.net

13531 discussions

RE: Problem with WINS registration on 5.3.4R3
by Bond, Andrew 04 Apr '00

04 Apr '00

Maybe the WINS server is not accessible to the filer (in which case there should be errors in the messages file). Some versions of ONTAP allow you to run "cifs testdc" and this will report whether the name was registered by WINS or by broadcast because the WINS server was not available (I think this shows as "WINS" or "WINS broadcast" respectively). It is also possible to disable wins registration for specific IP address using the -wins flag to ifconfig. Have you opened a call with NetApp support? There are other tools to debug this.... Regards, Andrew > -----Original Message----- > From: owner-dl-toasters(a)netapp.com > [mailto:owner-dl-toasters@netapp.com]On Behalf Of Johan Gillquist > Sent: 04 April 2000 07:16 > To: netapp mailing list > Subject: Problem with WINS registration on 5.3.4R3 > > > Hi all, > > I have have a problem with my F720 running 5.3.4R3, CIFS and NFS. The > toaster does not seem to register itself in WINS. When I run a "cifs > sessions" command it states "WINS servers: xxx.xxx.x....." > and it's the > correct address. When a check the WINS server there is no entry's for > the filer. If I enter a static entry in the WINs database it > works fine > > Suggestions ? > > /Johan >

1 0

Problem with WINS registration on 5.3.4R3
by Johan Gillquist 04 Apr '00

04 Apr '00

Hi all, I have have a problem with my F720 running 5.3.4R3, CIFS and NFS. The toaster does not seem to register itself in WINS. When I run a "cifs sessions" command it states "WINS servers: xxx.xxx.x....." and it's the correct address. When a check the WINS server there is no entry's for the filer. If I enter a static entry in the WINs database it works fine Suggestions ? /Johan

1 0

RE: Legato NetApp Client Pak = weak
by Graydon Dodson 03 Apr '00

03 Apr '00

> Is anyone else using the Legato Client Pak for NetApp? The fact that it > doesn't support the GUI doesn't bother me, but I *do* have a problem that I > have to manually restart the daemon on the filer after every reboot. There > doesn't seem to be a way to start if from the rc file, as you have to type > the filer's password. We have had MAJOR problems using Legato's client pack for NetApp. Both with filler panics and with bad backups. My recommendation would be to avoid it. > Does anyone have insight into whether or not Legato will be expanding this > product? Legato's answer to us was to give us a free license to BudTool. But it's future is far from certain. Thanks. Graydon Dodson grdodson(a)lexmark.com Lexmark International Inc.

1 0

Legato NetApp Client Pak = weak
by Timothy Demarest 03 Apr '00

03 Apr '00

Is anyone else using the Legato Client Pak for NetApp? The fact that it doesn't support the GUI doesn't bother me, but I *do* have a problem that I have to manually restart the daemon on the filer after every reboot. There doesn't seem to be a way to start if from the rc file, as you have to type the filer's password. Does anyone have insight into whether or not Legato will be expanding this product? Ti

1 0

RE: How are you mounting CIFS homedirs with Win9x?
by Mohler,Anissa 03 Apr '00

03 Apr '00

You have hit the issue exactly... basically can't do that in 95 - not on Filers or NT Servers. Here are the two options I explored in my implementation of a filer in a CIFS only environment at my old job. I ended up using option #2 with batch files to ease the pain. I just couldn't get kixtart to run consistently. You can do some searches on MS's web site exact command to add in your batch file to automatically assign the user home directory in the NT Profile. Unfortunately I don't have the batch file myself anymore. Two options: #1 You can use a program like WINSET.EXE and a logon script processor like KiXtart to set the environment variable then map a drive for the 95 user in the same manner he would map the drive for the NT users. (Microsoft's web site has some good KB articles on this). #2 You can manually (or through batch file) set the Home Directory property (in NT User Manager for Domains under User Properties/Profile) to the desired home directory for each user. E.g. You would have to set the Home Directory property for your 95 users to Connect Z: (or whatever letter) to \\filer\username. Then you can use the native NT login script to map the 95 users to NET USE Z: /HOME This topic is pretty well covered on Microsoft's web site. Another option you can try is just place a shortcut to the filer on the users desktop. Then they could doubleclick on the filer and they will see their user home directory at the top level. Not as slick as some of the other options, but it should work as well. Hope this helps. :-----Original Message----- :From: Timothy Demarest [mailto:demarest@arraycomm.com] :Sent: Friday, March 31, 2000 10:05 AM :To: toasters(a)mathworks.com :Subject: How are you mounting CIFS homedirs with Win9x? : : : :I was wondering how everyone is mounting CIFS file systems :from Windows 9x :clients? Having worked through the NIS netgroup issue (Bug :#19922, patched :in 5.3.4R3P2 -- thanks everyone), I'm moving on to getting the :new filer :working with PCs. : :I have a CIFS homedir for each user. The filer shares this directory so :that it appears as the user name. In a Windows NT login :script, I can use :the "%username%" directive to mount the user's home dir as H:. :However, you :can't use "%username%" with Windows 9x clients. : :One option is to set the home directory in the user's :environment profile :(in User Manager), but this requires changing each user's profile. The :logon script is simple and elegant. : :I'd really like to mount the CIFS homedir directly, rather :than having the :user open the drive, then open the folder with their :associated username in :order to access files in their home directory. : :Any hints? : :Tim : :

2 1

Use of Netapp as DMZ "glue" device - possible?
by Jim Klun 7183 03 Apr '00

03 Apr '00

I am contemplating this architecture: INTERNET | CISCO PIX FW ------- DMZ FTP SERVER | | ------------------------------ | | | | NT CLIENT NETAPP The DMZ FTP Server would have an a UDP NFS mount THROUGH THE FIREWALL into the internal network. Inbound guest FTP would be directed there via the Netapp NFS mount. The NT box would have a covering SMB mount over the same filesystem. After a guest client delivers data to the FTP server it would be moved from the in to the out directory where it would be picked up by the internal NT box. Intent: Maintain an Internet-visible FTP server in the DMZ and yet provide easy access for inside servers. Question: 1. Does this make sense? Does anyopne use filers this way or in related ways? 2. Are there known exploits against filers doing UDP NFS as I describe above. Could the Netapp be attacked if the FTP box were hacked? 3. Related question: Can admin access to the filer be to ONLY the console port or ONLY a single interface? Thanks - Jim Klun * James A. Klun Sterling Commerce 4600 Lakehurst Ct. Dublin, Oh 43016 * * jklun(a)stercomm.com 614-793-7183 voice 614-793-7092 fax * * ---- "very like a whale" ---- * * ---- Hamlet, Act 2, Scene 2 ---- *

6 7

EMC Celerra vs NetApp Filer
by Gilles TOURPE 03 Apr '00

03 Apr '00

Hello, Did anybody get in the same site, an EMC Celerra system and a NETAPP F7xx ( at least 740 ) Filer ? I would be interrested in Performances, administration, supports issues ... I'm very curious about the Celerra solution. On the paper it looks smart and really really NAS-oriented ( quite funny for SAN-guys :-) ). Some tests we did we pretty concluant also ( and complex also ... ). Any thinking, remarks ???? Thanx Gilles ------------------------------------------------------------ Gilles TOURPE - System and Network Administrator APS BNP ARBITRAGE - Salle des marches ACTIONS - PARIS - France Phone : (33)-1-40-14-24-03 e-mail : gilles(a)bnpcn.com

2 1

Fwd: NetCache/NetApp Release 3.4
by Jamie Lawrence 03 Apr '00

03 Apr '00

From Bugtraq. -j >Approved-By: aleph1(a)SECURITYFOCUS.COM >Delivered-To: bugtraq(a)lists.securityfocus.com >Delivered-To: BUGTRAQ(a)SECURITYFOCUS.COM >X-Hate: Where do you want to go to die? >Date: Thu, 30 Mar 2000 10:16:08 +0200 >Reply-To: Michal Zalewski <lcamtuf(a)DIONE.IDS.PL> >Sender: Bugtraq List <BUGTRAQ(a)SECURITYFOCUS.COM> >From: Michal Zalewski <lcamtuf(a)DIONE.IDS.PL> >Subject: NetCache/NetApp Release 3.4 >X-To: BUGTRAQ(a)SECURITYFOCUS.COM >To: BUGTRAQ(a)SECURITYFOCUS.COM > >NetCache by Network Appliance (www.netapp.com) is one of the most popular >heavy-duty commercial proxy/cache application. In fact, it's rather poorly >written. We can't see the source code, but, some side effects instead. >There's a lot of them, but I'll try to focus on something called 'internal >requests' - requests that access proxy itself and are handled specially. > >For example, by connecting to proxy server and sending 'GET >http://proxy_server_itself:8080/disk_objects/help', we'll (usually) get >error message with this URL and a few stupid characters appended at the >end of it. It won't happen if you specify anything after 'help' - so I >believe it's something like broken sscanf() used to determine which help >object user wants. But that's not the point. Try appending slash and >approx 10k of 'A' letters to our request. In case of any other request >treated as 'external', it might result only in error message. But in this >case, with something around 9850 characters, our connection to proxy >server is immediately dropped... sounds familiar? I believe it's an >overflow. > >Another way to access it (urm, I mean, cause crash) is something like: >'GET disk_object://xx/AAAAA...'. Btw. I'm wondering there's anything >interesting available to download this way? There are some pictures, >disk_object://xx/help/graphics/help.gif and so on, but I haven't access to >NetCache box to check what else is inside... Aaaah, almost forgotten! Any >file within disk_object hierarchy might be downloaded as-is by appending >'/' to URL - for example, 'disk_object://xx/help/graphics/help.gif/' will >return text/plain dump of this GIF. This means, NetCache fails to classify >this file, so if there's any script or other special object, it won't be >recognized as something 'special'? > >-- > >Just to make everything clear - I haven't shell access to running NetCache >box, so I cannot verify I'm absolutely right - eg. if there's anything >interesting within disk_objects or what extactly happens, but I think >there's absolutely something wrong, and there's no excuse for poor, even >commercial, code. > >#include <stddiscl.h> // Standard Disclaimer applies > >_______________________________________________________ >Michal Zalewski * [lcamtuf(a)ags.pl] <=> [AGS WAN SYSADM] >[dione.ids.pl SYSADM] <-> [http://lcamtuf.na.export.pl] >[+48 22 551 45 93] [+48 603 110 160] bash$ :(){ :|:&};: >=-----=> God is real, unless declared integer. <=-----=

4 5

RE: Budtool v4.6.1 NDMP breaks with DOT 5.3.5P2
by Francett, Robert D (SAIC) 31 Mar '00

31 Mar '00

Our Veritas backups via NDMP also broke on reboot following upgrade to DOT5.3.5P2 from 5.3.4R2 (note Veritas not sanctioning 5.3.5anything yet to my knowledge). Got backups restarted, but not easy nor straight-forward. NetApp looking at it. We're downgrading to 5.3.4R3P2 per NetApp. Bob > ---------- > From: Jeff Krueger[SMTP:jkrueger@qualcomm.com] > Reply To: jkrueger(a)qualcomm.com > Sent: Friday, March 31, 2000 2:09 PM > To: Tim McDonough > Cc: Toaster > Subject: Re: Budtool v4.6.1 NDMP breaks with DOT 5.3.5P2 > > Tim: > > We're in the exact same situation. The first problem is that our tape > library device name is now called "mc0" instead of "spt0". This is > configured in the jbmgr_config file. > > Let us know if you figure this one out. We'll do the same if we figure > something out! =) > > -- Jeff > > > From Tim McDonough on Fri, 31 Mar 2000 13:00:54 PST: > > > >Howdy All: > > > > We were placed on the upgrade treadmill last week and > >upgraded > > our F740 cluster from v5.3.2D1 ( NDMP worked ) -- v5.3.4R3 > > -- v5.3.5P2 ( NDMP no worky ) > > > > Subsequently, our direct attached Budtool NDMP backups > >stopped > > working and timed out with each request. > > > > Anyone else seen this, solved this? > > > > Legato and NetApp are scratching their heads when they're not > > > > pointing their fingers at one another. > > > > Tim > > > > > > >

1 0

RE: Budtool v4.6.1 NDMP breaks with DOT 5.3.5P2
by Melvin, Grant 31 Mar '00

31 Mar '00

Hi Jeff, We've built in backwards compatibility, so that the jbmgr_config file can use "mco" or "spt0" even tough sysconfig -m only reports mc0. Hope this helps. Tim, I'd like to understand your issues with 5.3.5P2. Can you send me the case # logged with either NetApp or Legato support (or both)? Otherwise, please send me the symptoms. Cheers, Grant -----Original Message----- From: Jeff Krueger [mailto:jkrueger@qualcomm.com] Sent: Friday, March 31, 2000 3:10 PM To: Tim McDonough Cc: Toaster Subject: Re: Budtool v4.6.1 NDMP breaks with DOT 5.3.5P2 Tim: We're in the exact same situation. The first problem is that our tape library device name is now called "mc0" instead of "spt0". This is configured in the jbmgr_config file. Let us know if you figure this one out. We'll do the same if we figure something out! =) -- Jeff >From Tim McDonough on Fri, 31 Mar 2000 13:00:54 PST: > >Howdy All: > > We were placed on the upgrade treadmill last week and >upgraded > our F740 cluster from v5.3.2D1 ( NDMP worked ) -- v5.3.4R3 > -- v5.3.5P2 ( NDMP no worky ) > > Subsequently, our direct attached Budtool NDMP backups >stopped > working and timed out with each request. > > Anyone else seen this, solved this? > > Legato and NetApp are scratching their heads when they're not > > pointing their fingers at one another. > > Tim > > >

2 1

Jump to page:

2026

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