Davor Ocelic <[EMAIL PROTECTED]> wrote:
> On Mon, 5 Feb 2007 09:27:58 -0600 "Christopher D Clausen"
> <[EMAIL PROTECTED]> wrote:
>> Davor Ocelic <[EMAIL PROTECTED]> wrote:
>> > Adam, here are working mysql instructions:
>> >
>> > http://wiki.hcoop.net/wiki/DaemonAdmin/MySQL
>> >
>> > (The first part of it, which is appropriately marked, applies to
>> > both MySQL and Postgres).
>>
>> Was it decideded not to grant system:backup rl access on all the
>> volumes? (I thought it would be wise to setup a group that has read
>> access to everything, even if we aren't going to use it right now, it
>> might be useful in the future.)
>
> It was not decided. It's just that in the course of events
> (unplanned problems with mysql) I forgot to add it.
>
>> I'd also caution about making changes directly in root.cell all the
>> time. While this seems like a good idea, if something goes wrong and
>> the volume doesn't get released, all paths in the entire cell can be
>> broken. I'd recomend having the common/databases directory be a
>> seperate volume (containing only mount points) so that any problems
>> that occur during a volume release only affect the databases and not
>> potentially everything, including user home directories.
>>
>> Might be a good idea to grant the actual user "rl" access to this
>> volume so that they can cd into it and check the quota easier.
>> Might also make sense to have a "databases" group that contains both
>> mysql and postgres users so that there isn't a need to grant "l"
>> access to both on databases/USERNAME.
>
>
> Well, all valid points.
>
> I don't have time now, so please implement them yourself
> and edit wiki as appropriate.
I started to do this, but ran into a kernel problem:
(from dmesg)
------------[ cut here ]------------
kernel BUG at fs/namei.c:1381!
invalid opcode: 0000 [#1]
SMP
Modules linked in: openafs sunrpc ipmi_devintf ipmi_si ipmi_msghandler
ipv6 generic shpchp pci_hotplug ehci_hcd usbcore piix e1000 ext3 jbd
ide_disk ide_cd cdrom ide_core unix
CPU: 3
EIP: 0060:[<0006fefb>] Tainted: P VLI
EFLAGS: 00010202 (2.6.18.3-doc1 #1)
EIP is at may_delete+0x112/0x120
eax: e9176914 ebx: db36c080 ecx: dad10a80 edx: 00004001
esi: efd81114 edi: 00000001 ebp: dfb2a714 esp: dd327e54
ds: 0068 es: 0068 ss: 0068
Process mv (pid: 30117, ti=dd326000 task=f7a04030 task.ti=dd326000)
Stack: 0007923b c3106a40 000000d0 00000000 efd81114 00072082 db36c080
efd81114
00000001 dfb2a714 dd327ed4 ffffffea dd327f24 dd327ed4 00000000
00000000
dd327f24 dd327ed4 e658a000 000725b9 db36c080 efd81114 ca1f4d00
dfb2a714
Call Trace:
Code: 02 0f 44 d0 eb b6 ba fe ff ff ff eb af ba f0 ff ff ff eb a8 0f b7
40 28 ba eb ff ff ff 25 00 f0 00 00 3d 00 40 00 00 75 c4 eb 91 <0f> 0b
ea 04 78 5e c0 65 05 e9 0a ff ff ff 57 56 53 8b 74 24 10
EIP: [<0006fefb>] may_delete+0x112/0x120 SS:ESP 0068:dd327e54
I think the only way to clear this problem is with a reboot, but feel
free to try other things. I doubt that the openafs client can be
stopped though, due to the open file handles and hung ls processes.
I'll submit this as an openafs bug as well, but its obviously a problem.
Hopefully it won't occur once things are setup and working (or maybe
it'll be fixed in a newer openafs version.)
<<CDC
_______________________________________________
HCoop-SysAdmin mailing list
[email protected]
http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-sysadmin
