On Saturday, December 24, 2011 04:41:00 PM Rafael Skodlar did opine:
> On 12/23/2011 08:08 PM, gene heskett wrote:
> > On Friday, December 23, 2011 10:18:29 PM Jon Elson did opine:
> >> gene heskett wrote:
> >>> That has been done long ago Mark. The problem is that on pclos
> >>> (this box) gene is the first user, with a userid of 500. On
> >>> ubuntu, gene is also the first user 1000, so when user 500 tries to
> >>> copy a file to /home/user=1000 on ubuntu, its 100% no permissions.
> >>>
> >>> Now if the copy utilities used the username, and it was the same
> >>> $name on both machines, there is no clash.
> >>>
> >>> Cheers, Gene
> >>
> >> You should be able to create an alternate user (like gene2) and then
> >> create a group that allows
> >> access to both the 500 and 1000 users. I may have missed the start
> >> of this thread, I'm guessing
> >> this is a problem with a NFS file system? Seems like that would be
> >> the only time such
> >> cross-system IDs would matter.
> >
> > I have the *buntu box mounted at /mnt/shop, a samba share I believe.
> >
> >> From mounts output:
> > //shop.coyote.den/shop-slash on /mnt/shop type cifs (rw,mand)
> >
> > What I would like to be able to do, and which requires scp or sftp to
> > do, is fire up mc, send one pane to the *buntu box, the other to
> > wherever I have downloaded an emc useful file to here on this box,
> > and just hit an F5 to copy or an F6 to move it. I fail to see why
> > such a simple operation, where I am the user gene on both machines,
> > has to be such a %$#@()&^ pain in the ass.
>
> There is a number of ways to fix your problem but the following is
> likely the easiest way to do it. My setup: kubuntu workstation with
> openbox virtual machine(s). For test purposes I created a different user
> in one of VMs and then used the following method:
> * workstation
> - install sshfs
> - create a directory; for example ~/tmp/vm01
> - run the following commands:
> VM=vm11 or you could use IP# 192.168.3.185
> USR_REMOTE=rafaelx
> sshfs $USER@VM:/home/${USR_REMOTE} tmp/vm01
>
> * VM (virtual machine) or other Unix system
> - enable ssh connection, possibly use auto login with ssh key
>
> Now I can copy files or dirs back and forth using cp, rsync, mc or
> whatever on my workstation side. I tried it both ways and the files
> changed ownership as expected so that I have right ownership on either
> side. No need to mess with passwd file or anything else.
>
> If you want gui, install krusader which has the same functionality as mc
> with a lot of excellent candy! krusader (from KDE) is standalone and
> does not need sshfs I believe.
>
> I employ these three methods securely between the systems on LANs and
> the Internet: Linux, BSD, Solaris.
>
> > Why can't there be an option in these file management utility's to
> > tell them, not to use the user number for the perms checking, but the
> > user name instead? All this bs would disappear in a puff of
> > invisible smoke instead of all the blue smoke I generate because it
> > takes me 10 minutes to reread the manpages several times, and likely
> > 20 tries to get the proper command line syntax constructed from the
> > totally obtuse man pages of scp and sftp.
>
> It's not BS but I agree with what you say about the man pages. Too many
> man pages suck because they don't give you any examples of how to use
> the command. Old Unix problem.
>
> Still, the way things are is important for security reasons. It keeps
> improving for the most part but you cannot make too drastic changes as
> that breaks too many home grown utilities in large installations.
>
> What you could do is to setup a user on one system to be in the same
> group as the user in the other system and/or vice versa. In addition,
> you would need to change umask (002) to have users create group writable
> directories and files.
>
> > Could this be such a matter as "security=user" in the cifs.conf files
> > on both machines? On checking, that option is set on this box. And
> > now is set on shop.coyote.den too, it was share before on that
> > machine.
>
> Why bother with mosquito carrying viruses as it's inherently insecure
> and messy when you can fly in fortress? While samba can provide
> ownership change for the files when you copy them between the systems,
> it's something I will NEVER use between Unix systems when NFS is
> superior!
>
> You can setup automounter which will let you mount directories from any
> system with NFS. Check /etc/auto.* files. After it's setup, you can use
> autofs as a regular user, no root intervention needed. For example:
> in /etc/auto.master enable
> /net -hosts
>
> Sometimes you need to change /etc/auto.net because some implementations
> were broken in the past.
>
> /etc/exports <--- file tells what to export.
> /home/rafaelx 192.168.3.0/24(rw,sync)
>
> Put IP# and hostname in /etc/hosts. Restart NFS server daemon after you
> make changes
None of the files named above exist on this system even though the nfs
packages are installed. No packages labeled as autofs are available or
installed.
So I installed webmin, then let it update itself. Found the networking
link and tried to setup the export of my Download directory, but when
applying it, it spit out the usual nfs failure stanza:
rpc.nfsd: no process found
rpc.nfsd: writing fd to kernel failed: errno 111 (Connection refused)
rpc.nfsd: unable to set any sockets for nfsd
Next?
> Use:
> On workstation
> ls /net/<hostname>
> will give you names of directories exported by <hostname>. You can then
> do whatever depending on the permissions.
>
> Install autofs on the client side and nfs-kernel-server on the serving
> side. You could do the same on both sides if you have enough resources
> and want to play with it.
>
> ls /net/vm01
> shows what's exported on that system.
>
> ll /net/vm01/home/rafaelx/8020
> gives me a list of files
>
> df | grep net
> Filesystem 1K-blocks Used Available Use% Mounted on
> vm01:/home/rafaelx 7739904 4168832 3177920 57%
> /net/vm01/home/rafaelx
>
> One of the greatest benefits about autofs is in its unmount after some
> time of no use, unless you did a cd into it or have an open file. That
> eliminates unnecessary traffic.
>
> This is a bit more time consuming to setup and suitable for office
> environment.
Which sounds like a good idea.
>
> > Humm, mc can now copy stuff, but "fails to chown" the file. So as I
> > have an ssh session going as gene, go check, and gene:gene owns
> > everything I copied there with this copy session.
>
> No need. sshfs takes care of it. I just tried it with mc and cp.
>
> > So, now I have a way to do it without screwing around till my blood
> > pressure is up 40 points. Next I need to scan back through this list
> > and find some code that was uploaded 2 or 3 weeks ago that I need on
> > that machine.
> >
> > As for NFS, I have spent many hours trying to configure NFS, but the
> > failure rate is 100% forever. I gave up on it when, on another
> > mailing list I was sent config files guaranteed to work, but never
> > did. I gave up on it 3 or 4 installs back and haven't tried since.
>
> Config files somewhat depend on distribution and you cannot simply copy
> them from one system to another.
>
> > That may also be due to the differences in usernum base systems for
> > all I know. The error messages are obtuse and rarely make sense to
> > those who claim to know something about NFS. Can't get sockets and
> > such.
> >
> > I'd better git-r-done for the night Jon, thanks for listening.
> >
> >> Jon
> >
> > Cheers, Gene
>
> Merry Christmas,
And of course a healthy, happy, and prosperous New Year too.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
You are standing on my toes.
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
