toasters January 2009

toasters@lists.teaparty.net

44 participants
32 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

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 January 2009