Re: How to determine /dev/ad* from mount label
On 04/27/2010 00:04, Carl Johnson wrote: Mark G.mark-fbsd-quest-10+20100...@giovannetti.ca writes: [...] I just wanted to know if there was a utility to tell me which actual device was mounted. I also tried camcontrol devlist and atacontrol list. The latter allowed me to determine that /dev/label/rootfs0 is ad2s1a based on the actual disk size and a process of elimination. Does anyone know a magic incantation to output this label-device mapping? Try looking at glabel(8). I don't know what option will list which is mounted, but 'glabel status' shows the names and what partitions they are associated with. That's the ticket, I knew I was missing something. Thanks! Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
How to determine /dev/ad* from mount label
Hi, I've tried the mount, tunefs and df manuals, and don't know where to look next. I am trying to find out what device, in terms of /dev/ad0s1a and so on, is actually 'connected' to a label mounted file system. Here is my fstab (from PC-BSD, by the way): # more /etc/fstab # Device Mountpoint FStype Options Dump Pass /dev/label/rootfs0 / ufs rw,noatime 1 1 /dev/label/swap0none swapsw 0 0 /dev/label/var0 /var ufs rw,noatime 1 1 /dev/label/usr0 /usr ufs rw,noatime 1 1 procfs /proc procfs rw 0 0 linprocfs /compat/linux/proc linprocfs rw0 0 tmpfs /tmp tmpfs rw,mode=17770 0 I just wanted to know if there was a utility to tell me which actual device was mounted. I also tried camcontrol devlist and atacontrol list. The latter allowed me to determine that /dev/label/rootfs0 is ad2s1a based on the actual disk size and a process of elimination. Does anyone know a magic incantation to output this label-device mapping? Thanks Mark P.S. The latest FreeBSD 8 under PC-BSD is really quite good. My thanks to everyone involved. Picked up a copy at the freebsdmall with the guide. Excellent. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Subversion and FreeBSD permission problems
David Kelly wrote: On Mar 23, 2008, at 11:01 AM, Darrell Blake wrote: If I move into a temp directory and do svn checkout file:///usr/local/svn/repository/TestProject it works fine but if I do svn svn://127.0.0.1/TestProject I get an error stating svn: Can't connect to host '127.0.0.1': Connection refused. Also, if I try and use TortoiseSVN to browse the repository externally I get an error stating Error * Can't connect to host '192.168.0.10': No connection could be made because the target machine actively refused it. What does the output of `sockstat -4` look like? It should list the SVN server's listening port. I suggest using svn+ssh: rather than svn: Then so long as you can ssh into the machine you can do svn. Here is a short paper I wrote about SVN over SSH on FreeBSD. https://www.giovannetti.ca/bsd/SubversionOnFreeBSDWithSSH.pdf Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Subversion and FreeBSD permission problems
Hi Darrell, Please don't top post. Further help follows. Darrell Blake wrote: I'm SSHing to my server from my desktop as I haven't actually got a monitor on the server but when I do a sockstat I get the following output regarding svn: svusersvnserve 846 3 tcp6 *:3690*:* When I try and do telnet 127.0.0.1 3690 on the server I get... telnet: connect to address 127.0.0.1: Connection refused. telnet: Unable to connect to remote host ...and if I try and do telnet 192.168.0.10 3690 from my desktop I get... Connecting To 192.168.0.10...Could not open connection to the host, on port 3690 : Connect failed I'm not opposed to using SVN via SSH but I'd kind like to get a vanilla SVN server going first. It's becoming an unusually steep learning curve =o) I wonder if you have inetd running and intercepting these connections--not likely, but you can check. Have you gone through the /path-to-repository/conf/svnserve.conf file and twiddled with any of the settings in there? Check man svnserve.conf and man svnserve (there's a debug setting for the server that might provide some clues as to why connections are failing). Particularly, in svnserve.conf(5) is: anon-access = none|read|write Determines the access level for unauthenticated users. write access allows all repository operations. read access allows all operations except committing and changing revision properties. none access allows no access. The default level is read. auth-access = none|read|write ... Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Subversion and FreeBSD permission problems
Hi again, Darrell Blake wrote: I'm SSHing to my server from my desktop as I haven't actually got a monitor on the server but when I do a sockstat I get the following output regarding svn: svusersvnserve 846 3 tcp6 *:3690*:* I just noticed the 'tcp6' in the above line. Looks like your svn server is listening on an IP version 6 address. It won't answer a request made from an IP version 4 address (it can't even see it), which is what 127.0.0.1 and 192.168.*.* are. Does the output to 'sockstat -4' show any services? Note the -4 option restricts sockstat's output to IP v4 addresses. Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default acl's permissions problem [continuation?]
Nathanael Jean-Francois wrote: Hi all, I've run into the little snag with default acl permissions, the issue was brought up in this thread http://marc.theaimsgroup.com/?l=freebsd-questionsm=18504532207w=2 but there was no reply to it and my digging so far hasn't turned up anything substantial. If anyone knows of a solution for this please let me know. Thanks -Nathanael Hello, I don't understand the acl and mask support for defaults. But I have found a way to make them work as I *think* they should. Here is an example similar to the one in the link you provided. # mount /dev/ad2s1h on /home (ufs, local, soft-updates, acls) # cd /home # mkdir cvsroot # chown cvs:cvs cvsroot # chmod 2770 cvsroot # ls -la drwxrws--- 2 cvs cvs512 Jun 17 23:46 cvsroot/ # umask 22 # touch cvsroot/te # ls -la cvsroot/te -rw-r--r-- 1 root cvs 0 Jun 17 23:48 cvsroot/te # umask 0007 - this turns out to be the solution. # touch cvsroot/tes # ls -la cvsroot/tes -rw-rw 1 root cvs 0 Jun 18 02:00 cvsroot/tes Now for the acls part. # setfacl -d -m u::rwx,m::rwx,g::rwx,o::--- cvsroot/ # getfacl -d cvsroot/ #file:cvsroot/ #owner:1012 #group:1012 user::rwx group::rwx mask::rwx other::--- Ok, so far so good. # touch cvsroot/test # getfacl cvsroot/test #file:cvsroot/test #owner:0 #group:1012 user::rw- group::rwx # effective: rw- mask::rw- other::--- Hmmm. Ok, so it didn't make it executable. A good thing. Add some groups to the default acl on cvsroot/ # setfacl -d -m g:cvsuser:r-x,g:cvsadmin:rwx cvsroot/ # getfacl -d cvsroot/ #file:cvsroot/ #owner:1012 #group:1012 user::rwx group::rwx group:cvsuser:r-x group:cvsadmin:rwx mask::rwx other::--- Now the acl entries on cvsroot/ itself: # setfacl -m g:cvsuser:r-x,g:cvsadmin:rwx cvsroot/ # getfacl cvsroot/ #file:cvsroot/ #owner:1012 #group:1012 user::rwx group::rwx group:cvsuser:r-x group:cvsadmin:rwx mask::rwx other::--- What I Want 1. All new files created to be read for cvsuser. 2. New directories to be read/exec for cvsuser. 3. All files created to be read/write for cvsadmin. 4. New directories to be read/write/exec for cvsadmin. 5. The defaults will propagate down the tree so that sub-sub directories inherit the same permissions. 6. The user and group cvs has full control. 7. Any other users have no permissions. What I Get # mkdir cvsroot/dir1 # touch cvsroot/file1 # ls -lad cvsroot/* drwxrwx---+ 2 root cvs 512 Jun 18 02:19 cvsroot/dir1/ -rw-rw+ 1 root cvs0 Jun 18 02:19 cvsroot/file1 Looks OK from that angle. Items 6 and 7 are satisfied. # getfacl cvsroot/* #file:cvsroot/dir1 #owner:0 #group:1012 user::rwx group::rwx group:cvsuser:r-x group:cvsadmin:rwx mask::rwx other::--- Good. Items 2 and 4 are satisfied. #file:cvsroot/file1 #owner:0 #group:1012 user::rw- group::rwx # effective: rw- group:cvsuser:r-x # effective: r-- group:cvsadmin:rwx # effective: rw- mask::rw- other::--- Better. Items 1 and 3 are satisfied. Finally: # getfacl -d cvsroot/dir1 #file:cvsroot/dir1 #owner:0 #group:1012 user::rwx group::rwx group:cvsuser:r-x group:cvsadmin:rwx mask::rwx other::--- # touch cvsroot/dir1/file2 # mkdir cvsroot/dir1/dir2 # ls -lad cvsroot/dir1/* drwxrwx---+ 2 root cvs 512 Jun 18 02:26 cvsroot/dir1/dir2/ -rw-rw+ 1 root cvs0 Jun 18 02:26 cvsroot/dir1/file2 # getfacl -d cvsroot/dir1/dir2/ #file:cvsroot/dir1/dir2/ #owner:0 #group:1012 user::rwx group::rwx group:cvsuser:r-x group:cvsadmin:rwx mask::rwx other::--- # getfacl cvsroot/dir1/dir2/ #file:cvsroot/dir1/dir2/ #owner:0 #group:1012 user::rwx group::rwx group:cvsuser:r-x group:cvsadmin:rwx mask::rwx other::--- # getfacl cvsroot/dir1/file2 #file:cvsroot/dir1/file2 #owner:0 #group:1012 user::rw- group::rwx # effective: rw- group:cvsuser:r-x # effective: r-- group:cvsadmin:rwx # effective: rw- mask::rw- other::--- Excellent. Item 5 is satisfied. Those are all my requirements. This entire discovery process, although nice and tidy above, was filled with a certain amount of grief. It was only until I reset the umask to 0007 that things started to work as expected. Now this bothers me for two reasons. I don't want my umask to have to be 0007. What if I'm in a working directory that doesn't require propagating acls? Then I'm stuck setting my umask back to something sensible like 0027 before creating files without extended acl entries. I have a difficult time remembering little details like that. Not only that, but I'll have to remember to set it back to 0007 (or maybe , horrors) if I want to use propagating acls and have them behave as I expect as shown above. I can easily set a process' umask through cron et al, but how do I set it for cvs users using the protocol :ext:server:/home/cvsroot with ssh? Can anyone explain this further? Thanks. Mark P.S. Below is the behaviour that perplexed me earlier. It is not what I expect and does not meet my
