FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 08-02-2011, 04:40 AM
Jatin K
 
Default NFS shared directory permission (rhel6)

On Monday 01 August 2011 08:11 PM, 夜神 岩男 wrote:
> On 08/01/2011 10:25 PM, Jatin K wrote:
>> On Monday 01 August 2011 06:41 PM, 夜神 岩男 wrote:
>>> On 08/01/2011 09:59 PM, Robert Marcano wrote:
>>>> On 08/01/2011 08:03 AM, 夜神 岩男 wrote:
>>>> ...
>>>>
>>>>> NFSv4 has become both more awesome and more complex.
>>>>> Before getting into specific issues that can cause this...
>>>>>
>>>> If you intend to use POSIX ACLs with NFSv4 forget about it, because user
>>>> umask is always applied at the client side over the default POSIX ACLs
>>>> making difficult to have for example rw directory/files for some group
>>>> of users.
>>> That is part of what I am trying to discover by asking him for the
>>> output I wrote and more about the authentication/authorization situation
>>> on the network. There are a large number of reasons permissions can get
>>> kajiggered over the network with NFSv4 or AFS, and in an office
>>> environment doubly so because of the prevalence of LDAP, NIS and
>>> Kerberos deployments, along with SELinux fun tossed in.
>>>
>>> -Iwao
>> no there is no LDAP or NIS like stuff
>>
>> I'm thinking to use ACL on that directory based on the user groups ( in
>> my scenario it will be office user groups )
> You can achieve the same user and group permissions on the clients as on
> the server, but you have to create the users and groups on the server
> side to get this and you must use some form of authentication across the
> network. The server exports the user names and group names, not the
> numbers, so a translation must occur within rpc.idmapd as well. Its not
> as hard as it sounds -- most of it "just works" once you set up
> authentication.
>
> This can happen through the /etc/passwd and /etc/groups files, using
> them as a local directory (which is easy, because this is already the
> default -- in a directory-enabled environment this is easier to maintain
> over the long run, though).
>
> Create the users and groups on the server that exist on your clients.
> Don't worry about the UID and GID numbers matching, they don't need to.
> Make sure the user and group names are the same, though.
>
> Then make sure that you do:
> setsebool -P nfs_export_all_ro=0
> setsebool -P nfs_export_all_rw=1
>
> and that in your /etc/exports you have the correct permissions declared
> for the export. It is also easier to manage a lot of shares if you are
> using the fsid=0 style export directory trees, though I don't think this
> is strictly necessary.
>
> And, critically... you must pick an authentication mechanism that
> rpc.idmapd likes.
>
> The easiest one is Kerberos, and its really not that difficult to set
> up. Once a Kerberos ticket exists for authentication, then the NFS
> server will believe that you're really user@EXAMPLE.COM and that the
> system you're on is really host/client.example.com@EXAMPLE.COM with a
> valid credential to use nfs/client.example.com@EXAMPLE.COM at
> nfs/server.example.com@EXAMPLE.COM and pass UID/GID information to the
> client.
>
> You don't really *need* directory services like LDAP or NIS, but without
> using authentication I don't think there is a way to get NFSv4 to pass
> UID/GID information. The reason is that passing this data leaves it up
> to the client to decide how to handle security, and that is not secure
> at all.
>
> For example, if you had "192.168.0.0/24(rw)" in your /etc/exports then
> anyone who gets into your wireless could just declare UIDs and GIDs and
> do whatever they wanted with your data (from a security perspective it
> is the same thing as exporting mod 777 shares). By requiring
> authentication this problem goes away, and by removing anonymous
> authentication as an option the temptation to screw yourself also goes
> away. In other words if you're exporting mod 777 you have to explicitely
> set things up that way with NFSv4, and this is a Good Thing.
>
> There are a lot of threads out there by people who don't understand how
> authenticated NFSv4 works, most of them ranting about how "stupid"
> idmapd, Kerberos, LDAP, or nsswitch is -- or they are just threads where
> people declare, en masse, that "permissions over NFSv4 just can't
> happen" in a despairing tone. But again, these people don't understand
> how the system functions very well.
>
> I have really been meaning to collect my notes about small/medium office
> Kerberos/LDAP/NFSv4 setup and write a small series on how to do this
> without giving up, settling for less (ie. logically unauthenticated
> Samba or using just LDAP as if it were actually an authentication
> service and a directory), or jumping off of a bridge.
>
> If you run into bad spots, keep asking. If I actually write a how-to
> about this I'll send you a link. Beware that most of the how-tos out
> there are pretty out of date, don't take SELinux into account or make
> other assumptions that don't line up with RPM-based systems (or do
> boneheaded things like say "Step 1, turn off SELinux").
>
> -Iwao

Thank you very very much for you efforts ..... its really a informative
lines


Thanks again

--
°v°
/(_)
^ ^ Jatin Khatri
Registerd Linux user No #501175
www.counter.li.org
No M$

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-02-2011, 03:12 PM
夜神 岩男
 
Default NFS shared directory permission (rhel6)

On 08/02/2011 01:09 AM, Mike Wright wrote:
> On 08/01/2011 07:41 AM, 夜神 岩男 wrote:
>> I have really been meaning to collect my notes about small/medium office
>> Kerberos/LDAP/NFSv4 setup and write a small series on how to do this
>> without giving up, settling for less (ie. logically unauthenticated
>> Samba or using just LDAP as if it were actually an authentication
>> service and a directory), or jumping off of a bridge.
>>
>> If you run into bad spots, keep asking. If I actually write a how-to
>> about this I'll send you a link. Beware that most of the how-tos out
>> there are pretty out of date, don't take SELinux into account or make
>> other assumptions that don't line up with RPM-based systems (or do
>> boneheaded things like say "Step 1, turn off SELinux").
>>
>
> Thanks for your efforts, Iwao.
>
> Sign me up, too. A link would be *great*.
>
> One of my biggest plaints is that much of the documentation out there
> lacks date and/or version info.
>
> Now that I've got Xen up and going and have more than a few virtual
> machines running it's becoming difficult/awkward to keep track of
> users/passwords, dealing with uid/gid being different for the same users
> on different machines, and especially nfs. Some vms will happily mount
> from one nfs server while others to the same server give me errors, all
> with the same version of the same o/s.

Great need plants great seed, doesn't it? (Whoa! That sort of sounds
like old wisdom! English is fun!)

> (Unfortunately, in order to debug my setup I've resorted to "Step 1",
> which sometimes helps and other times not so much.)

I supposed Step 2 should always be set to "revert Step 1"!

I will put my notes together and make a series out of it -- looking
around the web and in books this sort of thing really *doesn't* seem to
be documented well and stumps a huge number of people who just give up
and assume that good Linux setups are just too hard to bother with. This
is because:

1. The cn=config style of OpenLDAP is undocumented and very confusing
for newcomers

(Initial setup for the first time reliably produces feelings between
simmering-rage-type frustration or the breaking-things-in-the-office
point. Some things the OpenLDAP manual should have in it under
configuration just aren't there, and it makes the manual *feel*
inaccurate though it doesn't actually state anything that is wrong...
which is worse, because it makes it believable *and* wrong instead of
clearly, igorably wrong...)

2. Kerberos seems scary at first and though quite simple to understand
after playing with it a bit, the documentation goes to such length to
"make a hard subject easy" that the reader defaults to the assumption
that it *is* hard -- which is not as true as it may feel.

(...and the part when you decide that you're actually going to switch
authentication over is a little nerve-wracking so some admins just don't
go through with it -- its like the first time you decided to actually
turn SSH password authentication off on a really remote system, but
multiplied by however many systems your servicing raised to the power of
however much your contract is worth)

3. Our users have been trained to expect such shit tech from whatever
contact they had with bad Windows administration in the past that we can
get away with being lazy and not doing things correctly. ("Put it on the
shared drive" comes to mind...)

(The Post-Windows Crutch -- where we continue to not let users
experience seamless networking to the natural degree, where they don't
even realize what terminal they are using because everything is the same
from every station -- because its all the same system if things are
working the way they were originally designed)

4. The interactions between the little team of necessary daemons is so
scantily explained that most admins that get to the point of an actually
complete configuration fail because unthought-of-yet-critical daemons
aren't started. Two of the biggest culprits on Fedora are nscd and nslcd.

(The last sentence above is today's hint -- discovered after seeing what
would happen if a working SL6 setup was pushed directly to a Fedora 14
system. nscd, nslcd weren't even installed with the dependencies for the
setup, and sssd was present in the system but no scripts that require it
(like authconfig-tui) called "chkconfig sssd on" for some reason... Of
course none of these problems produced remotely accurate error messages
any place that the uninitiated would think to look (or at all)...)

5. CA and signed-certificate creation is a fun subject full of myth and
wildly inaccurate or out of date tutorials (or tutorials specific to,
say, FreeBSD or Darwin/OSX, but don't clearly state that). Its confusing
and ill-treated enough that some people give up and just shell out money
for them, even if the certification is strictly internal.

6. NFSv4 and OpenAFS are great tools, but suffer from a lack of accurate
documentation in a similar way to the CA subject. Why is sort of beyond
me, because they are both widely deployed, but only by people who either
paid to learn the magical secrets (and after climbing the learning curve
myself, I have to say this is probably a worthwhile option) or were
burned about the time they understood everything and were too worn out
thinking on the subject to post their notes (I think most of us can
appreciate that feeling after certain experiences).

Blah blah blah. Yes, an in-depth tutorial is sorely needed (really this
calls for another O'Reilly book in my opinion, but you'll have to settle
for whatever I've got spare time for + outdated web resources and...
man/info pages -- haha!).

-Iwao

PS: I've got to finish a magazine article that Akemi Yagi and I are
writing for a Japanese journal out here (she's the main author, not me,
but its hard doing English/Japanese, so this is more time consuming than
usual for me) -- so this will have to wait just a little. I'll post to
the list when I'm done, though, or at least send you folks a private
notice. Not sure that it really applies to everyone here so much as to
warrant plugging my tutorial on-list...
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-02-2011, 04:06 PM
Ian Malone
 
Default NFS shared directory permission (rhel6)

2011/8/1 夜神 岩男 <supergiantpotato@yahoo.co.jp>:
> On 08/01/2011 10:25 PM, Jatin K wrote:
>> On Monday 01 August 2011 06:41 PM, 夜神 岩男 wrote:
>>> On 08/01/2011 09:59 PM, Robert Marcano wrote:
>>>> On 08/01/2011 08:03 AM, 夜神 岩男 wrote:
>>>> ...
>>>>
>>>>> NFSv4 has become both more awesome and more complex.
>>>>> Before getting into specific issues that can cause this...
>>>>>
>>>> If you intend to use POSIX ACLs with NFSv4 forget about it, because user
>>>> umask is always applied at the client side over the default POSIX ACLs
>>>> making difficult to have for example rw directory/files for some group
>>>> of users.
>>> That is part of what I am trying to discover by asking him for the
>>> output I wrote and more about the authentication/authorization situation
>>> on the network. There are a large number of reasons permissions can get
>>> kajiggered over the network with NFSv4 or AFS, and in an office
>>> environment doubly so because of the prevalence of LDAP, NIS and
>>> Kerberos deployments, along with SELinux fun tossed in.
>>>
>>> -Iwao
>>
>> no there is no LDAP or NIS like stuff
>>
>> I'm thinking to use ACL on that directory based on the user groups ( in
>> my scenario it will be office user groups )
>
> You can achieve the same user and group permissions on the clients as on
> the server, but you have to create the users and groups on the server
> side to get this and you must use some form of authentication across the
> network. The server exports the user names and group names, not the
> numbers, so a translation must occur within rpc.idmapd as well. Its not
> as hard as it sounds -- most of it "just works" once you set up
> authentication.
>
> This can happen through the /etc/passwd and /etc/groups files, using
> them as a local directory (which is easy, because this is already the
> default -- in a directory-enabled environment this is easier to maintain
> over the long run, though).
>
> Create the users and groups on the server that exist on your clients.
> Don't worry about the UID and GID numbers matching, they don't need to.
> Make sure the user and group names are the same, though.
>
> Then make sure that you do:
> setsebool -P nfs_export_all_ro=0
> setsebool -P nfs_export_all_rw=1
>
> and that in your /etc/exports you have the correct permissions declared
> for the export. It is also easier to manage a lot of shares if you are
> using the fsid=0 style export directory trees, though I don't think this
> is strictly necessary.
>
> And, critically... you must pick an authentication mechanism that
> rpc.idmapd likes.
>
> The easiest one is Kerberos, and its really not that difficult to set
> up. Once a Kerberos ticket exists for authentication, then the NFS
> server will believe that you're really user@EXAMPLE.COM and that the
> system you're on is really host/client.example.com@EXAMPLE.COM with a
> valid credential to use nfs/client.example.com@EXAMPLE.COM at
> nfs/server.example.com@EXAMPLE.COM and pass UID/GID information to the
> client.
>
> You don't really *need* directory services like LDAP or NIS, but without
> using authentication I don't think there is a way to get NFSv4 to pass
> UID/GID information. The reason is that passing this data leaves it up
> to the client to decide how to handle security, and that is not secure
> at all.
>
> For example, if you had "192.168.0.0/24(rw)" in your /etc/exports then
> anyone who gets into your wireless could just declare UIDs and GIDs and
> do whatever they wanted with your data (from a security perspective it
> is the same thing as exporting mod 777 shares). By requiring
> authentication this problem goes away, and by removing anonymous
> authentication as an option the temptation to screw yourself also goes
> away. In other words if you're exporting mod 777 you have to explicitely
> set things up that way with NFSv4, and this is a Good Thing.
>
> There are a lot of threads out there by people who don't understand how
> authenticated NFSv4 works, most of them ranting about how "stupid"
> idmapd, Kerberos, LDAP, or nsswitch is -- or they are just threads where
> people declare, en masse, that "permissions over NFSv4 just can't
> happen" in a despairing tone. But again, these people don't understand
> how the system functions very well.
>
> I have really been meaning to collect my notes about small/medium office
> Kerberos/LDAP/NFSv4 setup and write a small series on how to do this
> without giving up, settling for less (ie. logically unauthenticated
> Samba or using just LDAP as if it were actually an authentication
> service and a directory), or jumping off of a bridge.
>
> If you run into bad spots, keep asking. If I actually write a how-to
> about this I'll send you a link. Beware that most of the how-tos out
> there are pretty out of date, don't take SELinux into account or make
> other assumptions that don't line up with RPM-based systems (or do
> boneheaded things like say "Step 1, turn off SELinux").
>

Thanks for posting that, very handy and I know how long these things
take to write.

--
imalone
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-02-2011, 04:51 PM
Tom H
 
Default NFS shared directory permission (rhel6)

On Mon, Aug 1, 2011 at 8:57 AM, Steve Searle <steve@stevesearle.co.uk> wrote:
>
> I know. If you read my website it says that the firewall can cause a
> file to be read-only.

Which firewall settings cause NFS exports to be ro?
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-02-2011, 05:05 PM
Tom H
 
Default NFS shared directory permission (rhel6)

2011/8/1 夜神 岩男 <supergiantpotato@yahoo.co.jp>:


> You can achieve the same user and group permissions on the clients as on
> the server, but you have to create the users and groups on the server
> side to get this and you must use some form of authentication across the
> network. The server exports the user names and group names, not the
> numbers, so a translation must occur within rpc.idmapd as well. Its not
> as hard as it sounds -- most of it "just works" once you set up
> authentication.
>
> This can happen through the /etc/passwd and /etc/groups files, using
> them as a local directory (which is easy, because this is already the
> default -- in a directory-enabled environment this is easier to maintain
> over the long run, though).
>
> Create the users and groups on the server that exist on your clients.
> Don't worry about the UID and GID numbers matching, they don't need to.
> Make sure the user and group names are the same, though.
>
> Then make sure that you do:
> setsebool -P nfs_export_all_ro=0
> setsebool -P nfs_export_all_rw=1
>
> and that in your /etc/exports you have the correct permissions declared
> for the export. It is also easier to manage a lot of shares if you are
> using the fsid=0 style export directory trees, though I don't think this
> is strictly necessary.
>
> And, critically... you must pick an authentication mechanism that
> rpc.idmapd likes.
>
> The easiest one is Kerberos, and its really not that difficult to set
> up. Once a Kerberos ticket exists for authentication, then the NFS
> server will believe that you're really user@EXAMPLE.COM and that the
> system you're on is really host/client.example.com@EXAMPLE.COM with a
> valid credential to use nfs/client.example.com@EXAMPLE.COM at
> nfs/server.example.com@EXAMPLE.COM and pass UID/GID information to the
> client.
>
> You don't really *need* directory services like LDAP or NIS, but without
> using authentication I don't think there is a way to get NFSv4 to pass
> UID/GID information.

NFSv4 works without Kerberos or LDAP/NIS/NIS+.

The username and idmapd domain have to match (perhaps the UID too but
I've never tried different UIDs as you suggest above and the
description of idmapd does say that the ID is sent as
username@domain).
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-02-2011, 05:32 PM
夜神 岩男
 
Default NFS shared directory permission (rhel6)

On 08/03/2011 02:05 AM, Tom H wrote:

> NFSv4 works without Kerberos or LDAP/NIS/NIS+.

Of course it does, but can the permissions be exported per user by
UID/GID mask or are the exports still blanket ro/rw (which is the real
point of this thread)? Further, can you escape from the nfs_mount_t
context and give native SELinux contexts to the export on the client
side with this setup?

(That would be really cooking from one perspective, but also pretty
insecure without authentication -- which is why I had always been under
the impression that this was specifically forbidden.)

> The username and idmapd domain have to match (perhaps the UID too but
> I've never tried different UIDs as you suggest above and the
> description of idmapd does say that the ID is sent as
> username@domain).

That would be neat.

Can you direct me to a sample idmapd configuration that achieves this:
rpc.idmapd + hostname-declared domains that are common (does DNS need to
be enabled for this?) + /etc/passwd and /etc/group files + NFSv4 UIDs
and GIDs accurately mapped for permissions across exports (not just ro
or blanket rw).

It could fill in some holes and perhaps I've just never been able to
find the right way to make idmapd domains stick with SELinux enabled
without using some form of authentication. Is sssd or nslcd or nscd
required somewhere in there, or do these just satisfy Kerberos requirements?

If I can get a configuration like this working it would help the OP in
the short run, and provide more insight for the tutorial I want to write.

-Iwao
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-02-2011, 07:57 PM
Steve Searle
 
Default NFS shared directory permission (rhel6)

Around 05:51pm on Tuesday, August 02, 2011 (UK time), Tom H scrawled:

> On Mon, Aug 1, 2011 at 8:57 AM, Steve Searle <steve@stevesearle.co.uk> wrote:
> >
> > I know. If you read my website it says that the firewall can cause a
> > file to be read-only.
>
> Which firewall settings cause NFS exports to be ro?

I already pointed to the webpage. Its here:
http://www.stevesearle.com/tech/faq.html#nfs0010

I'm not going to rewrite it in an email

Steve

--

Play Champions - my free football predictions game at:
http://www.stevesearle.com/champs/about.html

20:55:28 up 1 day, 12:15, 1 user, load average: 0.00, 0.02, 0.00
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-02-2011, 09:59 PM
Tom H
 
Default NFS shared directory permission (rhel6)

On Tue, Aug 2, 2011 at 3:57 PM, Steve Searle <steve@stevesearle.co.uk> wrote:
> Around 05:51pm on Tuesday, August 02, 2011 (UK time), Tom H scrawled:
>> On Mon, Aug 1, 2011 at 8:57 AM, Steve Searle <steve@stevesearle.co.uk> wrote:
>> >
>> > I know. If you read my website it says that the firewall can cause a
>> > file to be read-only.
>>
>> Which firewall settings cause NFS exports to be ro?
>
> I already pointed to the webpage. Its here:
> http://www.stevesearle.com/tech/faq.html#nfs0010
>
> I'm not going to rewrite it in an email

Where on your page does it say: "to export an nfs share r/o, use the
following iptables rules?"
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-03-2011, 04:49 AM
夜神 岩男
 
Default NFS shared directory permission (rhel6)

On 08/03/2011 04:57 AM, Steve Searle wrote:
> Around 05:51pm on Tuesday, August 02, 2011 (UK time), Tom H scrawled:
>
>> On Mon, Aug 1, 2011 at 8:57 AM, Steve Searle<steve@stevesearle.co.uk> wrote:
>>>
>>> I know. If you read my website it says that the firewall can cause a
>>> file to be read-only.
>>
>> Which firewall settings cause NFS exports to be ro?
>
> I already pointed to the webpage. Its here:
> http://www.stevesearle.com/tech/faq.html#nfs0010
>
> I'm not going to rewrite it in an email

This is not what I have experienced with NFSv4. NFSv3 had specific port
requirements for random rpc daemons, but with NFSv4 you only need TCP
2049 open (or whatever you set it to) -- that was one of the more
tangible improvements over the previous versions.

And this is what I meant about documentation on the subject being
generally out of date or not accurate as per the current Linux standard
(as in, not Solaris circa 2001 documentation...).

The following iptables were exported from a server running SSH (tcp 22)
OpenLDAP (tcp 389), NFSv4 (tcp 2049) and Kerberos KDC/Kadmin (88 and
749). This server provides rw exports with authenticated rw file
permissions and correct SELinux contexts for several shares:

# Generated by iptables-save v1.4.7 on Wed Aug 3 13:41:04 2011
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4538677:6498063300]
-A INPUT -p tcp -m tcp --dport 88 -j ACCEPT
-A INPUT -p udp -m udp --dport 88 -j ACCEPT
-A INPUT -p udp -m udp --dport 749 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 749 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2049 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 389 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Wed Aug 3 13:41:04 2011

-Iwao
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 

Thread Tools




All times are GMT. The time now is 03:03 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org