toasters

toasters@lists.teaparty.net

13520 discussions

fakeroot on a mixed qtree not working properly.
by Page, Jeremy 06 Jan '09

06 Jan '09

The info below was sent to me by one of our engineers. I also tried switching the qtree to UNIX instead of mixed but it gives me an error "qtree update: qtree security style update: qtree: There are shares with connections on qtree" Any suggestions? Below is an example of fakeroot not working properly. First I present what should happen (this is on a local machine not using my network drive) kuebert@gsows-eng138:~/tmp$ mkdir foo kuebert@gsows-eng138:~/tmp$ ls -l total 4 drwxr-xr-x 2 kuebert kuebert 4096 2009-01-05 15:52 foo/ kuebert@gsows-eng138:~/tmp$ fakeroot chown root:root foo kuebert@gsows-eng138:~/tmp$ ls -l total 4 drwxr-xr-x 2 kuebert kuebert 4096 2009-01-05 15:52 foo/ kuebert@gsows-eng138:~/tmp$ touch foo/bar kuebert@gsows-eng138:~/tmp$ ls -l foo total 0 -rw-r--r-- 1 kuebert kuebert 0 2009-01-05 15:52 bar kuebert@gsows-eng138:~/tmp$ fakeroot chown root:root foo/bar kuebert@gsows-eng138:~/tmp$ ls -l foo total 0 -rw-r--r-- 1 kuebert kuebert 0 2009-01-05 15:52 bar kuebert@gsows-eng138:~/tmp$ rm -rf foo kuebert@gsows-eng138:~/tmp$ This is what happens on my network home drive (I did this on gsovm-psbs03): kuebert@gsovm-psbs01:~/tmp2$ mkdir foo kuebert@gsovm-psbs01:~/tmp2$ ls -l total 4 drwxr-xr-x 2 kuebert cvs 4096 2009-01-05 15:51 foo/ kuebert@gsovm-psbs01:~/tmp2$ fakeroot chown root:root foo kuebert@gsovm-psbs01:~/tmp2$ ls -l total 4 drwxr-xr-x 2 root root 4096 2009-01-05 15:51 foo/ kuebert@gsovm-psbs01:~/tmp2$ touch foo/bar touch: cannot touch `foo/bar': Permission denied kuebert@gsovm-psbs01:~/tmp2$ rm -rf foo kuebert@gsovm-psbs01:~/tmp2$ So basically what I think is happening is in the second case my fakeroot command is actually changing the file on the filesystem, at least from Linux's perspective, even though it's not supposed to. When I go to touch the file in the foo directory it won't let me because it thinks the directory is owned by root:root which it is not. Due to a problem like this I can't build deb packages without being root which is kind of a big deal (the dir permissions get hosed up and then the package creation fails). Jeremy M. Page________________ Systems Architect Gilbarco Veeder-Root, a Danaher Company 7300 West Friendly Avenue Greensboro, NC 22087 * email:Jeremy.Page@gilbarco.com - * phone: 336.547.5399 - 6 fax: 336.547.5163 - * cell: 336.601.7274 Open a Helpdesk Ticket <http://heat.gilbarco.com/heatselfservice/simple/en-us/> View the IT Wiki <http://gsovmwiki01.gilbarco.com/mediawiki/index.php/Main_Page> Please be advised that this email may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender and by telephone (call us collect at +1 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance. In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email.

2 1

Upgarding filer head with LUNs and MSCS
by Borzenkov, Andrey 05 Jan '09

05 Jan '09

Hi, We are going to upgrade several filers (FAS270 -> FAS3140). They host FCP LUNs and Windows with MSCS connected. Now what I have been told: - MSCS records disks (LUNs) serial numbers; when these serial numbers change, MSCS won't detect and configure its disks. Basically, cluster has to be recreated from scratch - LUN serial number on filer depends on sysid; when sysid changes, LUN serial number will change - as during head upgrade sysid will change so will serial numbers; so MSCS will be very unhappy. Is the above correct? Now we'd rather avoid recreating all MSCS configuration. Are there any pitfalls if we save original serial numbers and set them again on new head before MSCS will go online? Will this work or some more tuning is necessary? Thank you! С уважением / With best regards / Mit freundlichen Grüβen --- Andrey Borzenkov Senior system engineer

3 3

Success using Bacula to back up an iSCSI-only NetApp
by David Lee Lambert 23 Dec '08

23 Dec '08

We have a two-controller FAS2020 NetApp with 1.5TB of storage (1TB on one, 500GB on the other), licensed for iSCSI only, and an old desktop system connected to a 12-tape library of LTO-4 (800GB uncompressed) tapes. I have gotten Bacula to back up files stored on ext3fs (Linux) and NTFS (Windows) partions on iSCSI LUNs on the NetApp. The Bacula instance is running under Ubuntu Gutsy (a "long-term supported" release), using the Gutsy package, 2.0.3. We're using Postgres version 8.2.5 as the database, because that's the available Ubuntu package and we use Postgres elsewhere. We're using the "open-iscsi" initiator, from an Ubuntu package. LVM and device-mapper are not installed on the backup-host, and it only has a single Fast Ethernet connection. (The hosts that are being backed up generally have dual Gigabit Ethernet connections to the filers.) I wrote several scripts to allow Bacula to take snapshots on the filer and mount them in a known place before the backup-job runs, then clean them up afterward. I can't publish them because they have a lot of details specific to our network, but the general outline is as follows: "easy_snap" takes 3 arguments: an NTFS or ext3fs volume-label, an indication of which filer the volume is on, and the complete path to the LUN on the filer (such as "/vol/vol5/testdatav2.lun"). It makes up a name to use for the snapshot. It issues "snap create", "lun clone create" and "lun map" commands via RSH to the filer. (It also checks to see if another snapshot of the same volume is still mounted by mistake; if so, it unmounts and unmaps it.) If another snapshot with the same name exists, the script tries to delete it, and renames it if that doesn't work. It cleans up any old "bacula-" snapshots. Then it issues a local "iscsiadm -m session --rescan" command, and if it still can't see the new LUN, logs the iSCSI session out and in again. It mounts the partition using "LABEL=" syntax, to a mount-point under /mnt where the last part is the lower-case form of the volume-label. "easy_unsnap" takes the same 3 arguments as "easy_snap". It unmounts the partition, logs out the iSCSI session, unmaps the LUN, and tries to delete the snapshot. We noticed that the snapshots weren't always being deleted, which is one reason why "easy_snap" tries to clean up old snapshots several ways. If a backup spans an hour-boundary where hourly snapshots are being created, or midnight for the nightly snapshot, the mapped LUN becomes part of the snapshot and the snapshot we took can't be deleted until the hourly or nightly snapshot goes away. I tried backing up Linux hosts with a filesystem on a raw (no partions) LUN using this script, but it didn't work: when the LUN is discovered, the /dev/disk/by-label/LABEL symlink does not get created. We wouldn't be able to back up LVM volumes with this configuration either, because LVM depends on device-mapper, and device-mapper would try to grab the disks itself. Right now our performance is limited by the network interface for LUNs containing a few large files, and by Postgres INSERT performance for filesystems with lots of small files. We get 9MByte/sec for the big-file LUNs, so for example a 46-GB SQL Server database takes an hour and 18 minutes to run. We have a test-system with over 300,000 files (including over 100,000 zero-length ones) in just a few directories, but only 580 MB of total data; that took two and a half hours to back up last night. However, our entire backup (except test-systems) ran within 6 hours, and we already have more than half of our production data being backed up with Bacula. For the most part, Bacula does what we want it to do in this case, and it allows a lot more flexibility with restoring files than we were able to achieve trying to use the "dump" command on the NetApp filers. -- David L. Lambert Yahoo! IM: davidleelambert ** MSN IM: lamber45(a)cse.msu.edu

1 0

Limiting SnapDrive user capabilities
by Borzenkov, Andrey 23 Dec '08

23 Dec '08

Hi, We are looking for a possibility to limit SnapDrive account to the bare minimum. The goal is to allow some SD operations (effectively, connecting and disconnecting snapshots) to a (Windows) user, while not giving this user full administrative capabilities on a filer. I have a feeling that careful usage of roles on filer could accomplish this; anybody has done it before? I would appreciate any hints. Thank you and Merry Christmas! С уважением / With best regards / Mit freundlichen Grüβen --- Andrey Borzenkov Senior system engineer

2 1

SMVI Command Line questions
by hollandwl＠gmail.com 23 Dec '08

23 Dec '08

Just started evaluating SMVI 1.01 in our Dev environment to get a feel for how it works. A couple of things showed up immediately that I could use some clarification on: 1. Is there any way to get it to simply pass the logged on Windows credentials and not prompt for a password the first time? The current behavior totally defeats the ability to script the operations as we do not wish to store passwords in clear text. 2. Is there any way to have it create backups/snapshots in a user friendly format? Using the -backup-name switch puts the name you enter into the snapshot name, but you still end up with something like smvi-backupname-someobscenelylonguid-volname. This naming convention makes integration with snapvault difficult as I know what name I pass with -backup-name, but don't know what the hiddeously long name is going to be. It would be EXTREMELY helfpful if the snapshot name were the same as -backup-name passed on the command line.

1 0

RE: Quick question about "LUN protocol type"
by David L. Lambert 19 Dec '08

19 Dec '08

OK, I guess I phrased my question poorly. I want to make a LUN that will only be accessed by a Linux host. It will have a partition-table, and one partition in that partition-table. That partition will have a labeled ext3fs filesystem on it (Ubuntu's "mount LABEL=..." seems more reliable if I do it that way). Should I tell the NetApp that it's a "Windows" or a "Linux" LUN? Or will the NetApp behave exactly the same either way? -- David Lee Lambert -----Original Message----- From: Jeff Mohler [mailto:speedtoys.racing@gmail.com] Subject: Re: Quick question about "LUN protocol type" Why not map two Luns? ___ Sent from my $400 phone that has no text editing tools. Yay. On Dec 15, 2008, at 7:59 AM, David Lee Lambert <dlambert(a)bmtcarhaul.com> wrote: > In the FilerView LUN wizard, I see the following options for "LUN > protocol > type": > > [...] > > If we're making a LUN with a DOS partition table and one partiton that will be used by a Linux host, should we use the "Windows" or "Linux" setting? Or does it matter? > > -- > David L. Lambert > Yahoo! IM: davidleelambert ** MSN IM: lamber45(a)cse.msu.edu

2 1

Serial console cable shenanigans (FAS3020s to Cyclades)
by Nick Silkey 16 Dec '08

16 Dec '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 toasters -- I am trying to troubleshoot connectivity issues between my serial consoles and my 3020s. Per NetApp, we are 'required' to hang the X881[1] rj45-to-db9 dongle off the filers. But my Cyclades can easily grok rj-45. A phone call to NetApp revealed that a pin-out of: 4 -> 4 3 -> 6 6 -> 3 should allow me to not have to used the NetApp dongle (TSE appears to have walked the pin-outs backwards to come up with the above). Havent tested this yet; looking to confirm from those on the list since the pinout is non-standard. So is anyone out there tapping into their Cyclades without the NetApp db9 dongle hanging off their 3xx0 filer? Insight appreciated. Thanks. [1]: http://now.netapp.com/NOW/knowledge/solutions/kb13794_X881.jpg ; taken from https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb13794 - -- Nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklGkAgACgkQrDQjhjXrMeJX7gCfUol7uWHNjlE8m0R1gC863CqK dqYAniNUoFg4mrgC9LNjJ09vO3VKkBAh =UPnp -----END PGP SIGNATURE-----

1 1

Leopard globalSAN iSCSI and 7.1.3
by Carl Howell 15 Dec '08

15 Dec '08

On one of our Xserve¹s, I¹ve used the Studio Network Solution¹s iSCSI initiator(3.3.0.43) with OnTap version 7.0.5 and didn¹t have any problems. Now, after upgrading to OnTap version 7.1.3, I get the following error: Mon Dec 15 16:18:36 CST [iscsi.protocol.violation:warning]: ISCSI: iSCSI protocol violation, 'Initiator did not respond to offered MaxBurstLength' Does anyone have any ideas on how to fix this? Thanks, --Carl

1 0

Re: Quick question about "LUN protocol type"
by David Lee Lambert 15 Dec '08

15 Dec '08

No, when I say a "DOS partition table" I mean what I get by running the program "/sbin/fdisk" under Linux, and subsequently doing e.g. mke2fs -L APPDATA -j /dev/sde1 instead of just doing mke2fs -L APPDAT -j /dev/sde On Monday 15 December 2008 11:19:48 am Webster, Stetson wrote: > Question: Is DOS directly interfacing with the lun? Do you have SAN device > drivers for DOS? > -----Original Message----- > From: David Lee Lambert [mailto:dlambert@bmtcarhaul.com] > Subject: Quick question about "LUN protocol type" > > In the FilerView LUN wizard, I see the following options for "LUN protocol > type": > [...] > > If we're making a LUN with a DOS partition table and one partiton that will > be used by a Linux host, should we use the "Windows" or "Linux" setting? > Or does it matter? -- David L. Lambert Software Developer, Precision Motor Transport Group, LLC Work phone 517-349-3011 x223 Cell phone 586-873-8813

1 0

Quick question about "LUN protocol type"
by David Lee Lambert 15 Dec '08

15 Dec '08

In the FilerView LUN wizard, I see the following options for "LUN protocol type": Solaris Windows - "The LUN will be used to store a raw disk device in a single-partition Windows disk" HP-UX AIX Linux - "The LUN will be used to store a Linux raw disk with no partition table" NetWare VMware The "na_snap" manpage also lists the types "windows_gpt" and "vld". If we're making a LUN with a DOS partition table and one partiton that will be used by a Linux host, should we use the "Windows" or "Linux" setting? Or does it matter? -- David L. Lambert Yahoo! IM: davidleelambert ** MSN IM: lamber45(a)cse.msu.edu

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