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
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.
>
> 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,
--
Rafael
------------------------------------------------------------------------------
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
