compartilhamento NFS
Boa noite, Estou tentando colocar um 2o drive no meu servidor em casa via NFS com meu desktop e não está dando certo. Nesse servidor eu já tenho um drive acessível, via NFS. Esse segundo é que não consigo enxergar. servidor: hosts.allow portmap: 192.168.1.100/105 lockd: 192.168.1.1000/105 rquotad: 192.168.1.100/105 mountd: 192.168.1.100/105 statd: 192.168.1.100/105 hosts.deny portmap:ALL lockd:ALL mountd:ALL rquotad:ALL statd:ALL arquivo exports /mnt/multimedia 192.168.1.0/255.255.255.0(rw,no_root_squash,no_subtree_check,crossmnt,fsid=0) /mnt/midia5 192.168.1.0/255.255.255.0(rw,no_root_squash,no_subtree_check,crossmnt,fsid=0) /exports 192.168.1.0/255.255.255.0(rw,no_root_squash,no_subtree_check,crossmnt,fsid=0) esse multimedia funciona...o midia5 é que não funciona. cliente: arquivo fstab #T800 via nfs 192.168.1.102:/ /exportsnfs4 soft,intr,rsize=8192,wsize=8192 192.168.1.102:/mnt/midia5/ /exports2 nfs4 soft,intr,rsize=8192,wsize=8192 A 1a linha funcionou para criar o compartilhamento, porém eu não entendo pq ele pega como / e não como /mnt/multimedia. Mas funcionou. Eu penso que o cliente teria que montar o drive exportado pelo server e minha intenção foi exportar /mnt/multimedia e não / . A 2 linha não via de jeito nenhum. mesmo tentando montar na mão ( lado cliente claro ): mount -t nfs 192.168.1.102:/mnt/midia5 /exports2 mount.nfs: requested NFS version or transport protocol is not supported Alguém pode dar uma luz na besteira que estou fazendo. Grato Luís Cláudio A. Gama Fones: TIM: 11-9 8452-4087 Res: 11-4602-3400 Skype: luisclaudiogama http://luisgama.googlepages.com br.linkedin.com/in/luisclaudiogama ||\|_ | Voto Distrital |||'|\__ |__|||_||) !(@)'(@)*!(@)(@)*!(@)portmap: 192.168.1.100/105 lockd: 192.168.1.1000/105 rquotad: 192.168.1.100/105 mountd: 192.168.1.100/105 statd: 192.168.1.100/105 -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajqdw71t2i3eo3i5xi-bzxv4yfd9ufj7gyg2_rky1gfsql7...@mail.gmail.com
Re: Montando compartilhamento NFS
Miguel Da Silva escreveu: Renato S. Yamane escribió: Pergunto: É possível informar o nome de usuário e senha como parâmetro para montar o NFS? Tentei com a tradicional opção username;passwd, porém não deu certo: # mount -t nfs -o username=USUÁRIO,passwd=SENHA 192.168.1.4:Setores setores/ mount.nfs: Bad nfs mount parameter: username Não tem jeito não. Se não houver um mecanismo de autenticação (NIS, LDAP, etc) o jeito é configurar no HP o diretório setores de maneira que o seu UID e GID coincidam com os que foram usados nas permissões do diretório. No meu laptop: $ id yamane uid=1000(yamane) gid=1000(yamane) grupos=1000(yamane),20(dialout),24(cdrom),25(floppy),29(audio),44(video), 46(plugdev),110(netdev),114(powerdev),1001(engenharia) Pedi para os administradores da rede (que é *Windows*) criarem uma conta yamane no grupo engenharia, porém ainda assim não é possível acessar o diretório montado: # mount -t nfs 192.168.1.10:Engenharia /mnt/engenharia # ls /mnt/engenharia/ ls: impossível abrir a pasta /mnt/engenharia: Permissão negada Pelo jeito, não basta a conta/grupo ter o mesmo nome. Pelo que eu pesquisei, o Windows não possui UID e nem GID, mas sim um tal de SystemID (SID). Agora a pergunta é totalmente fora de escopo: - Alguém sabe como vincular um UID/GID em um SID, no tal do Windows? Att, Renato -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Montando compartilhamento NFS
On Wednesday 18 February 2009 14:16:12 Renato S. Yamane wrote: Miguel Da Silva escreveu: Renato S. Yamane escribió: Pergunto: É possível informar o nome de usuário e senha como parâmetro para montar o NFS? Tentei com a tradicional opção username;passwd, porém não deu certo: # mount -t nfs -o username=USUÁRIO,passwd=SENHA 192.168.1.4:Setores setores/ mount.nfs: Bad nfs mount parameter: username Não tem jeito não. Se não houver um mecanismo de autenticação (NIS, LDAP, etc) o jeito é configurar no HP o diretório setores de maneira que o seu UID e GID coincidam com os que foram usados nas permissões do diretório. No meu laptop: $ id yamane uid=1000(yamane) gid=1000(yamane) grupos=1000(yamane),20(dialout),24(cdrom),25(floppy),29(audio),44(video), 46(plugdev),110(netdev),114(powerdev),1001(engenharia) Pedi para os administradores da rede (que é *Windows*) criarem uma conta yamane no grupo engenharia, porém ainda assim não é possível acessar o diretório montado: # mount -t nfs 192.168.1.10:Engenharia /mnt/engenharia # ls /mnt/engenharia/ ls: impossível abrir a pasta /mnt/engenharia: Permissão negada Pelo jeito, não basta a conta/grupo ter o mesmo nome. Pelo que eu pesquisei, o Windows não possui UID e nem GID, mas sim um tal de SystemID (SID). Agora a pergunta é totalmente fora de escopo: - Alguém sabe como vincular um UID/GID em um SID, no tal do Windows? Att, Renato Oi renato! Esse diretório que tu está tentando montar, é acessível via samba ? [ ]'s -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Montando compartilhamento NFS
Fabricio Cannini - Yahoo escreveu: Renato S. Yamane wrote: $ id yamane uid=1000(yamane) gid=1000(yamane) grupos=1000(yamane),20(dialout),24(cdrom),25(floppy),29(audio),44(video), 46(plugdev),110(netdev),114(powerdev),1001(engenharia) Pedi para os administradores da rede (que é *Windows*) criarem uma conta yamane no grupo engenharia, porém ainda assim não é possível acessar o diretório montado: # mount -t nfs 192.168.1.10:Engenharia /mnt/engenharia # ls /mnt/engenharia/ ls: impossível abrir a pasta /mnt/engenharia: Permissão negada Pelo jeito, não basta a conta/grupo ter o mesmo nome. Pelo que eu pesquisei, o Windows não possui UID e nem GID, mas sim um tal de SystemID (SID). Agora a pergunta é totalmente fora de escopo: - Alguém sabe como vincular um UID/GID em um SID, no tal do Windows? Esse diretório que tu está tentando montar, é acessível via samba? Sim, perfeitamente. Mesmo porque no samba eu consigo informar o nome de usuário: mount -t cifs -o username=USUÁRIO,passwd=SENHA,iocharset=utf8 //192.168.1.4/Engenharia/ /mnt/engenharia/ Mas o samba é muito lento. Existe um diretório com mais de 2.000 arquivos, e sempre na primeira vez que eu tenho que visualiza-lo é necessário aguardar uns 40 segundos até ele exibir todos os arquivos. Att, Renato -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Montando compartilhamento NFS
também acho Renato, aqui também possuimos um diretório com muitos arquivos e ele realmente fica lento. 2009/2/18 Renato S. Yamane yam...@diamondcut.com.br Fabricio Cannini - Yahoo escreveu: Renato S. Yamane wrote: $ id yamane uid=1000(yamane) gid=1000(yamane) grupos=1000(yamane),20(dialout),24(cdrom),25(floppy),29(audio),44(video), 46(plugdev),110(netdev),114(powerdev),1001(engenharia) Pedi para os administradores da rede (que é *Windows*) criarem uma conta yamane no grupo engenharia, porém ainda assim não é possível acessar o diretório montado: # mount -t nfs 192.168.1.10:Engenharia /mnt/engenharia # ls /mnt/engenharia/ ls: impossível abrir a pasta /mnt/engenharia: Permissão negada Pelo jeito, não basta a conta/grupo ter o mesmo nome. Pelo que eu pesquisei, o Windows não possui UID e nem GID, mas sim um tal de SystemID (SID). Agora a pergunta é totalmente fora de escopo: - Alguém sabe como vincular um UID/GID em um SID, no tal do Windows? Esse diretório que tu está tentando montar, é acessível via samba? Sim, perfeitamente. Mesmo porque no samba eu consigo informar o nome de usuário: mount -t cifs -o username=USUÁRIO,passwd=SENHA,iocharset=utf8 // 192.168.1.4/Engenharia/ /mnt/engenharia/ Mas o samba é muito lento. Existe um diretório com mais de 2.000 arquivos, e sempre na primeira vez que eu tenho que visualiza-lo é necessário aguardar uns 40 segundos até ele exibir todos os arquivos. Att, Renato -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Guilherme Cunha Grupo de Processamento Paralelo e Distribuído (G3PD) Wiki: http://www.guilhermecunha.com.br IM: guilhermecu...@jabber.org Ubuntu User number is # 21803 Linux user number # 470582
Re: Montando compartilhamento NFS
Renato S. Yamane escribió: Pessoal, Os responsáveis pela TI adquiriam um servidor HP e habilitaram o compartilhamento NFS para mim (que sou o único usuário Linux na empresa), porém ao tentar montar esse compartilhamento, eu fico impossibilitado de acessa-lo: # mount -t nfs 192.168.1.4:Setores setores/ # ls -la setores/ ls: impossível abrir a pasta setores/: Permissão negada Pergunto: É possível informar o nome de usuário e senha como parâmetro para montar o NFS? Tentei com a tradicional opção username;passwd, porém não deu certo: # mount -t nfs -o username=USUÁRIO,passwd=SENHA 192.168.1.4:Setores setores/ mount.nfs: Bad nfs mount parameter: username Att, Renato Não tem jeito não. Se não houver um mecanismo de autenticação (NIS, LDAP, etc) o jeito é configurar no HP o diretório setores de maneira que o seu UID e GID coincidam com os que foram usados nas permissões do diretório. Até. -- Miguel Da Silva Unidad de Recursos Informáticos Facultad de Ingeniería - http://www.fing.edu.uy Universidad de la República - http://www.rau.edu.uy -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Montando compartilhamento NFS
se vc quiser usa autenticação, use o sshfs...mas já vou avisando que ele é lento, pois todo o tráfego é encriptografado. abracos! 2009/2/17 Miguel Da Silva mdasi...@fing.edu.uy Renato S. Yamane escribió: Pessoal, Os responsáveis pela TI adquiriam um servidor HP e habilitaram o compartilhamento NFS para mim (que sou o único usuário Linux na empresa), porém ao tentar montar esse compartilhamento, eu fico impossibilitado de acessa-lo: # mount -t nfs 192.168.1.4:Setores setores/ # ls -la setores/ ls: impossível abrir a pasta setores/: Permissão negada Pergunto: É possível informar o nome de usuário e senha como parâmetro para montar o NFS? Tentei com a tradicional opção username;passwd, porém não deu certo: # mount -t nfs -o username=USUÁRIO,passwd=SENHA 192.168.1.4:Setores setores/ mount.nfs: Bad nfs mount parameter: username Att, Renato Não tem jeito não. Se não houver um mecanismo de autenticação (NIS, LDAP, etc) o jeito é configurar no HP o diretório setores de maneira que o seu UID e GID coincidam com os que foram usados nas permissões do diretório. Até. -- Miguel Da Silva Unidad de Recursos Informáticos Facultad de Ingeniería - http://www.fing.edu.uy Universidad de la República - http://www.rau.edu.uy -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Montando compartilhamento NFS
Pessoal, Os responsáveis pela TI adquiriam um servidor HP e habilitaram o compartilhamento NFS para mim (que sou o único usuário Linux na empresa), porém ao tentar montar esse compartilhamento, eu fico impossibilitado de acessa-lo: # mount -t nfs 192.168.1.4:Setores setores/ # ls -la setores/ ls: impossível abrir a pasta setores/: Permissão negada Pergunto: É possível informar o nome de usuário e senha como parâmetro para montar o NFS? Tentei com a tradicional opção username;passwd, porém não deu certo: # mount -t nfs -o username=USUÁRIO,passwd=SENHA 192.168.1.4:Setores setores/ mount.nfs: Bad nfs mount parameter: username Att, Renato -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Problemas com compartilhamento NFS
Pessoal, estou com um problema que já quase me descabelei aqui e não to sabendo resolver o problema.. Gostaria muito da ajuda de vocês.. Tenho um servidor NFS no qual tenho alguns diretórios compartilhados, usuários cadastrados e alguns grupos no qual os usuarios participam. Na máquina cliente eu adicionei um usuario e seus respectivos grupos, conforme está no servidor (com os mesmos UID e GID). Até aí tudo certo, o problema está no momento de acessar as pastas compartilhadas pela máquina cliente. Somente consigo acessar as pastas cuja o grupo dono do diretorio seja meu grupo primário, as outras pastas eu não consigo, mesmo fazendo parte dos grupos. Vou exemplificar para facilitar o entendimento: No servidor: servidor:/# id usuario uid=900(usuario) gid=900(secnac) grupos=900(secnac),902(ascom),500(carlos),915(casn),945(secnacpriv),1066(secnacatas),1067(fotos) Na máquina cliente: [EMAIL PROTECTED] :~$ id uid=900(usuario) gid=900(secnac) grupos=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip), 44(video),46(plugdev),104(scanner),112(netdev),113(lpadmin),115(powerdev),118(admin),500(carlos),900(secnac),902(ascom),915(casn),945(secnacpriv), 1066(secnacatas),1067(fotos) Esses são os grupos. Aí quando tento acessar uma pasta que o grupo é secnac eu consigo, já o que é do secnacpriv, por exemplo, eu nao consigo. Qual o problema hein? Me dêem uma luz por gentileza. Obrigado
Problemas com compartilhamento NFS
Pessoal, estou com um problema que já quase me descabelei aqui e não to sabendo resolver o problema.. Gostaria muito da ajuda de vocês.. Tenho um servidor NFS no qual tenho alguns diretórios compartilhados, usuários cadastrados e alguns grupos no qual os usuarios participam. Na máquina cliente eu adicionei um usuario e seus respectivos grupos, conforme está no servidor (com os mesmos UID e GID). Até aí tudo certo, o problema está no momento de acessar as pastas compartilhadas pela máquina cliente. Somente consigo acessar as pastas cuja o grupo dono do diretorio seja meu grupo primário, as outras pastas eu não consigo, mesmo fazendo parte dos grupos. Vou exemplificar para facilitar o entendimento: No servidor: servidor:/# id usuario uid=900(usuario) gid=900(secnac) grupos=900(secnac),902(ascom),500(carlos),915(casn),945(secnacpriv),1066(secnacatas),1067(fotos) Na máquina cliente: [EMAIL PROTECTED]:~$ id uid=900(usuario) gid=900(secnac) grupos=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip), 44(video),46(plugdev),104(scanner),112(netdev),113(lpadmin),115(powerdev),118(admin),500(carlos),900(secnac),902(ascom),915(casn),945(secnacpriv), 1066(secnacatas),1067(fotos) Esses são os grupos. Aí quando tento acessar uma pasta que o grupo é secnac eu consigo, já o que é do secnacpriv, por exemplo, eu nao consigo. Qual o problema hein? Me dêem uma luz por gentileza. Obrigado
RES: Problemas com compartilhamento NFS
Me tirem desta lista..já mandei diversos emails para remoção e não tiram De: Debian User [mailto:[EMAIL PROTECTED] Enviada em: quinta-feira, 6 de setembro de 2007 11:09 Para: debian-user-portuguese@lists.debian.org Assunto: Problemas com compartilhamento NFS Pessoal, estou com um problema que já quase me descabelei aqui e não to sabendo resolver o problema.. Gostaria muito da ajuda de vocês.. Tenho um servidor NFS no qual tenho alguns diretórios compartilhados, usuários cadastrados e alguns grupos no qual os usuarios participam. Na máquina cliente eu adicionei um usuario e seus respectivos grupos, conforme está no servidor (com os mesmos UID e GID). Até aí tudo certo, o problema está no momento de acessar as pastas compartilhadas pela máquina cliente. Somente consigo acessar as pastas cuja o grupo dono do diretorio seja meu grupo primário, as outras pastas eu não consigo, mesmo fazendo parte dos grupos. Vou exemplificar para facilitar o entendimento: No servidor: servidor:/# id usuario uid=900(usuario) gid=900(secnac) grupos=900(secnac),902(ascom),500(carlos),915(casn),945(secnacpriv),1066(secnacatas),1067(fotos) Na máquina cliente: [EMAIL PROTECTED] :~$ id uid=900(usuario) gid=900(secnac) grupos=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip), 44(video),46(plugdev),104(scanner),112(netdev),113(lpadmin),115(powerdev),118(admin),500(carlos),900(secnac),902(ascom),915(casn),945(secnacpriv), 1066(secnacatas),1067(fotos) Esses são os grupos. Aí quando tento acessar uma pasta que o grupo é secnac eu consigo, já o que é do secnacpriv, por exemplo, eu nao consigo. Qual o problema hein? Me dêem uma luz por gentileza. Obrigado
Re: bzip2 travou ao realizar backup em compartilhamento nfs
Em Dom, 2007-05-13 às 11:03 -0300, Joao Emanuel escreveu: Em 11/05/07, Fernando Faria Mariano[EMAIL PROTECTED] escreveu: Obrigado cara... vou procurar algumas opções de montagem pra ver se consigo deixar esse backup mais estavel... ou talvez utilizar estas ferramentas... como o rsync q vc citou... Em Sex, 2007-05-11 às 13:19 -0300, hamacker escreveu: Não sei se foi DHCP, provavelmente não. Mas pode ter caído momentaneamente sua rede, ou a placa de rede pipocou por alguns instantes no lado server/client causando instabilidade na rede NFS e o backup foi para as cucuias. Não gosto muito do NFS por causa disso, talvez com algumas opções extras na montagem ele funcione melhor, mas nas opções simples de montagem ele é muito sensivel à rede. Após perder muito backup em discos USBs eu aprendí a usar a opção de montagem sync que apesar de tornar o backup mais lento na unidade USB, tornou bem (e bota bem nisso) confiável o backup, talvez no NFS seja a mesma coisa, basta descobrir algum parametro na montagem que torna-o menos sensivel à rede. Também faço backup remoto, mas neste caso tenho usando o rsync e o sshfs+tar.gz A proposito o bzip(tar -j) é isso mesmo, ele estrangula a CPU. Ou voce usa um nice com prioridade mais baixa ou troca por gzip (tar -z). A diferença é pouca se voce levar em conta que o bzip demora muito para ganhar talvez nem 1%. Em 11/05/07, Fernando Faria Mariano[EMAIL PROTECTED] escreveu: Bom dia. A minha rotina de backup de meu servidor de arquivos está da seguinte forma. Ela é executada todas as madrugadas. tar jcvpf /compartilhamento/nfs/em/outro/servidor /diretorio/de/origem tenho este script para várias pastas, e todo dia quando chego pela manhã todo o backup já foi realizado com sucesso. Mas hoje na segunda pasta a ser realizado o backup, especificamento a pasta (/var), o programa bzip2 usado para compactação estava travado com uso de aproximadamente 95% da cpu e aumentando a carga do sistema. O micro onde está sendo realizada a cópia de segurança obtem seu endereço ip apartir de meu servidor de arquivos (que é a máquina que está executando o script de backup citado acima que travou o bzip2 e apresentou carga alta) Procurei nos logs do servidor onde está ativo o compartilhamento nfs e encontrei uma mensagem suspeita sobre o obtenção do endereço por dhcp. Segue alguns logs abaixo... (todos os logs abaixo foram retirados da máquina onde está ativo o compartilhamento nfs). /var/log/daemon.log May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67 May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2 May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492 seconds. /var/log/syslog May 11 04:49:47 ka006 -- MARK -- May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67 May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2 May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492 seconds. arquivo onde aconteceu o erro -rw-r--r-- 1 root root 75M 2007-05-11 05:01 /backup/fileserver/10-05-2007/var-10-05-2007.tar.bz2 Esta hora do arquivo var-10-05-2007.tar.bz2 está coincidindo com a hora em que a máquina renovou seu endereço ip. Será que pode ter sido está a causa do travamento do programa bzip2 que está sendo executado no servidor de arquivos? ou seja... neste pequeno intervalo de tempo da renovação ouve uma queda de conexão o e progrmaa travou??? ou isto é apenas coincidencia... pergunto isto, porque certa vez li que o protocolo dhcp ao chegar no meio do periodo de sua concessão renova sua concessão automaticamente... fazendo com que não exista queda de conexão... obs: após ter detectado que o programa bzip2 estava travado finalizei-o com o comando kill e enviando o sinal 9. Depois disso todo o script está sendo executado sem problemas... Agradeço desde já a atenção de todos... Fernando Faria Mariano Fernando só um alerta, o hamacker não está comentando sobre o rsync, mas sim sobre a flag sync que tem no NFS para fazer a sincronia entre os dispositivos, ok? Ok, atualmente estou usando async... qual seria melhor no ponto de vista de confiança no backup? sync ou async? Fernando Faria
Re: bzip2 travou ao realizar backup em compartilhamento nfs
Em 11/05/07, Fernando Faria Mariano[EMAIL PROTECTED] escreveu: Obrigado cara... vou procurar algumas opções de montagem pra ver se consigo deixar esse backup mais estavel... ou talvez utilizar estas ferramentas... como o rsync q vc citou... Em Sex, 2007-05-11 às 13:19 -0300, hamacker escreveu: Não sei se foi DHCP, provavelmente não. Mas pode ter caído momentaneamente sua rede, ou a placa de rede pipocou por alguns instantes no lado server/client causando instabilidade na rede NFS e o backup foi para as cucuias. Não gosto muito do NFS por causa disso, talvez com algumas opções extras na montagem ele funcione melhor, mas nas opções simples de montagem ele é muito sensivel à rede. Após perder muito backup em discos USBs eu aprendí a usar a opção de montagem sync que apesar de tornar o backup mais lento na unidade USB, tornou bem (e bota bem nisso) confiável o backup, talvez no NFS seja a mesma coisa, basta descobrir algum parametro na montagem que torna-o menos sensivel à rede. Também faço backup remoto, mas neste caso tenho usando o rsync e o sshfs+tar.gz A proposito o bzip(tar -j) é isso mesmo, ele estrangula a CPU. Ou voce usa um nice com prioridade mais baixa ou troca por gzip (tar -z). A diferença é pouca se voce levar em conta que o bzip demora muito para ganhar talvez nem 1%. Em 11/05/07, Fernando Faria Mariano[EMAIL PROTECTED] escreveu: Bom dia. A minha rotina de backup de meu servidor de arquivos está da seguinte forma. Ela é executada todas as madrugadas. tar jcvpf /compartilhamento/nfs/em/outro/servidor /diretorio/de/origem tenho este script para várias pastas, e todo dia quando chego pela manhã todo o backup já foi realizado com sucesso. Mas hoje na segunda pasta a ser realizado o backup, especificamento a pasta (/var), o programa bzip2 usado para compactação estava travado com uso de aproximadamente 95% da cpu e aumentando a carga do sistema. O micro onde está sendo realizada a cópia de segurança obtem seu endereço ip apartir de meu servidor de arquivos (que é a máquina que está executando o script de backup citado acima que travou o bzip2 e apresentou carga alta) Procurei nos logs do servidor onde está ativo o compartilhamento nfs e encontrei uma mensagem suspeita sobre o obtenção do endereço por dhcp. Segue alguns logs abaixo... (todos os logs abaixo foram retirados da máquina onde está ativo o compartilhamento nfs). /var/log/daemon.log May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67 May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2 May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492 seconds. /var/log/syslog May 11 04:49:47 ka006 -- MARK -- May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67 May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2 May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492 seconds. arquivo onde aconteceu o erro -rw-r--r-- 1 root root 75M 2007-05-11 05:01 /backup/fileserver/10-05-2007/var-10-05-2007.tar.bz2 Esta hora do arquivo var-10-05-2007.tar.bz2 está coincidindo com a hora em que a máquina renovou seu endereço ip. Será que pode ter sido está a causa do travamento do programa bzip2 que está sendo executado no servidor de arquivos? ou seja... neste pequeno intervalo de tempo da renovação ouve uma queda de conexão o e progrmaa travou??? ou isto é apenas coincidencia... pergunto isto, porque certa vez li que o protocolo dhcp ao chegar no meio do periodo de sua concessão renova sua concessão automaticamente... fazendo com que não exista queda de conexão... obs: após ter detectado que o programa bzip2 estava travado finalizei-o com o comando kill e enviando o sinal 9. Depois disso todo o script está sendo executado sem problemas... Agradeço desde já a atenção de todos... Fernando Faria Mariano Fernando só um alerta, o hamacker não está comentando sobre o rsync, mas sim sobre a flag sync que tem no NFS para fazer a sincronia entre os dispositivos, ok? -- Joao Emanuel Contador Linux (counter.li.org): 398782 Mensageiro Jabber: [EMAIL PROTECTED] (se quiser me em envie o seu endereço do seu mensageiro para incluir)
bzip2 travou ao realizar backup em compartilhamento nfs
Bom dia. A minha rotina de backup de meu servidor de arquivos está da seguinte forma. Ela é executada todas as madrugadas. tar jcvpf /compartilhamento/nfs/em/outro/servidor /diretorio/de/origem tenho este script para várias pastas, e todo dia quando chego pela manhã todo o backup já foi realizado com sucesso. Mas hoje na segunda pasta a ser realizado o backup, especificamento a pasta (/var), o programa bzip2 usado para compactação estava travado com uso de aproximadamente 95% da cpu e aumentando a carga do sistema. O micro onde está sendo realizada a cópia de segurança obtem seu endereço ip apartir de meu servidor de arquivos (que é a máquina que está executando o script de backup citado acima que travou o bzip2 e apresentou carga alta) Procurei nos logs do servidor onde está ativo o compartilhamento nfs e encontrei uma mensagem suspeita sobre o obtenção do endereço por dhcp. Segue alguns logs abaixo... (todos os logs abaixo foram retirados da máquina onde está ativo o compartilhamento nfs). /var/log/daemon.log May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67 May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2 May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492 seconds. /var/log/syslog May 11 04:49:47 ka006 -- MARK -- May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67 May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2 May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492 seconds. arquivo onde aconteceu o erro -rw-r--r-- 1 root root 75M 2007-05-11 05:01 /backup/fileserver/10-05-2007/var-10-05-2007.tar.bz2 Esta hora do arquivo var-10-05-2007.tar.bz2 está coincidindo com a hora em que a máquina renovou seu endereço ip. Será que pode ter sido está a causa do travamento do programa bzip2 que está sendo executado no servidor de arquivos? ou seja... neste pequeno intervalo de tempo da renovação ouve uma queda de conexão o e progrmaa travou??? ou isto é apenas coincidencia... pergunto isto, porque certa vez li que o protocolo dhcp ao chegar no meio do periodo de sua concessão renova sua concessão automaticamente... fazendo com que não exista queda de conexão... obs: após ter detectado que o programa bzip2 estava travado finalizei-o com o comando kill e enviando o sinal 9. Depois disso todo o script está sendo executado sem problemas... Agradeço desde já a atenção de todos... Fernando Faria Mariano
Re: bzip2 travou ao realizar backup em compartilhamento nfs
Não sei se foi DHCP, provavelmente não. Mas pode ter caído momentaneamente sua rede, ou a placa de rede pipocou por alguns instantes no lado server/client causando instabilidade na rede NFS e o backup foi para as cucuias. Não gosto muito do NFS por causa disso, talvez com algumas opções extras na montagem ele funcione melhor, mas nas opções simples de montagem ele é muito sensivel à rede. Após perder muito backup em discos USBs eu aprendí a usar a opção de montagem sync que apesar de tornar o backup mais lento na unidade USB, tornou bem (e bota bem nisso) confiável o backup, talvez no NFS seja a mesma coisa, basta descobrir algum parametro na montagem que torna-o menos sensivel à rede. Também faço backup remoto, mas neste caso tenho usando o rsync e o sshfs+tar.gz A proposito o bzip(tar -j) é isso mesmo, ele estrangula a CPU. Ou voce usa um nice com prioridade mais baixa ou troca por gzip (tar -z). A diferença é pouca se voce levar em conta que o bzip demora muito para ganhar talvez nem 1%. Em 11/05/07, Fernando Faria Mariano[EMAIL PROTECTED] escreveu: Bom dia. A minha rotina de backup de meu servidor de arquivos está da seguinte forma. Ela é executada todas as madrugadas. tar jcvpf /compartilhamento/nfs/em/outro/servidor /diretorio/de/origem tenho este script para várias pastas, e todo dia quando chego pela manhã todo o backup já foi realizado com sucesso. Mas hoje na segunda pasta a ser realizado o backup, especificamento a pasta (/var), o programa bzip2 usado para compactação estava travado com uso de aproximadamente 95% da cpu e aumentando a carga do sistema. O micro onde está sendo realizada a cópia de segurança obtem seu endereço ip apartir de meu servidor de arquivos (que é a máquina que está executando o script de backup citado acima que travou o bzip2 e apresentou carga alta) Procurei nos logs do servidor onde está ativo o compartilhamento nfs e encontrei uma mensagem suspeita sobre o obtenção do endereço por dhcp. Segue alguns logs abaixo... (todos os logs abaixo foram retirados da máquina onde está ativo o compartilhamento nfs). /var/log/daemon.log May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67 May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2 May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492 seconds. /var/log/syslog May 11 04:49:47 ka006 -- MARK -- May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67 May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2 May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492 seconds. arquivo onde aconteceu o erro -rw-r--r-- 1 root root 75M 2007-05-11 05:01 /backup/fileserver/10-05-2007/var-10-05-2007.tar.bz2 Esta hora do arquivo var-10-05-2007.tar.bz2 está coincidindo com a hora em que a máquina renovou seu endereço ip. Será que pode ter sido está a causa do travamento do programa bzip2 que está sendo executado no servidor de arquivos? ou seja... neste pequeno intervalo de tempo da renovação ouve uma queda de conexão o e progrmaa travou??? ou isto é apenas coincidencia... pergunto isto, porque certa vez li que o protocolo dhcp ao chegar no meio do periodo de sua concessão renova sua concessão automaticamente... fazendo com que não exista queda de conexão... obs: após ter detectado que o programa bzip2 estava travado finalizei-o com o comando kill e enviando o sinal 9. Depois disso todo o script está sendo executado sem problemas... Agradeço desde já a atenção de todos... Fernando Faria Mariano
Re: bzip2 travou ao realizar backup em compartilhamento nfs
Obrigado cara... vou procurar algumas opções de montagem pra ver se consigo deixar esse backup mais estavel... ou talvez utilizar estas ferramentas... como o rsync q vc citou... Em Sex, 2007-05-11 às 13:19 -0300, hamacker escreveu: Não sei se foi DHCP, provavelmente não. Mas pode ter caído momentaneamente sua rede, ou a placa de rede pipocou por alguns instantes no lado server/client causando instabilidade na rede NFS e o backup foi para as cucuias. Não gosto muito do NFS por causa disso, talvez com algumas opções extras na montagem ele funcione melhor, mas nas opções simples de montagem ele é muito sensivel à rede. Após perder muito backup em discos USBs eu aprendí a usar a opção de montagem sync que apesar de tornar o backup mais lento na unidade USB, tornou bem (e bota bem nisso) confiável o backup, talvez no NFS seja a mesma coisa, basta descobrir algum parametro na montagem que torna-o menos sensivel à rede. Também faço backup remoto, mas neste caso tenho usando o rsync e o sshfs+tar.gz A proposito o bzip(tar -j) é isso mesmo, ele estrangula a CPU. Ou voce usa um nice com prioridade mais baixa ou troca por gzip (tar -z). A diferença é pouca se voce levar em conta que o bzip demora muito para ganhar talvez nem 1%. Em 11/05/07, Fernando Faria Mariano[EMAIL PROTECTED] escreveu: Bom dia. A minha rotina de backup de meu servidor de arquivos está da seguinte forma. Ela é executada todas as madrugadas. tar jcvpf /compartilhamento/nfs/em/outro/servidor /diretorio/de/origem tenho este script para várias pastas, e todo dia quando chego pela manhã todo o backup já foi realizado com sucesso. Mas hoje na segunda pasta a ser realizado o backup, especificamento a pasta (/var), o programa bzip2 usado para compactação estava travado com uso de aproximadamente 95% da cpu e aumentando a carga do sistema. O micro onde está sendo realizada a cópia de segurança obtem seu endereço ip apartir de meu servidor de arquivos (que é a máquina que está executando o script de backup citado acima que travou o bzip2 e apresentou carga alta) Procurei nos logs do servidor onde está ativo o compartilhamento nfs e encontrei uma mensagem suspeita sobre o obtenção do endereço por dhcp. Segue alguns logs abaixo... (todos os logs abaixo foram retirados da máquina onde está ativo o compartilhamento nfs). /var/log/daemon.log May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67 May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2 May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492 seconds. /var/log/syslog May 11 04:49:47 ka006 -- MARK -- May 11 05:00:09 ka006 dhclient: DHCPREQUEST on eth0 to 192.169.3.2 port 67 May 11 05:00:09 ka006 dhclient: DHCPACK from 192.169.3.2 May 11 05:00:09 ka006 dhclient: bound to 192.169.3.6 -- renewal in 257492 seconds. arquivo onde aconteceu o erro -rw-r--r-- 1 root root 75M 2007-05-11 05:01 /backup/fileserver/10-05-2007/var-10-05-2007.tar.bz2 Esta hora do arquivo var-10-05-2007.tar.bz2 está coincidindo com a hora em que a máquina renovou seu endereço ip. Será que pode ter sido está a causa do travamento do programa bzip2 que está sendo executado no servidor de arquivos? ou seja... neste pequeno intervalo de tempo da renovação ouve uma queda de conexão o e progrmaa travou??? ou isto é apenas coincidencia... pergunto isto, porque certa vez li que o protocolo dhcp ao chegar no meio do periodo de sua concessão renova sua concessão automaticamente... fazendo com que não exista queda de conexão... obs: após ter detectado que o programa bzip2 estava travado finalizei-o com o comando kill e enviando o sinal 9. Depois disso todo o script está sendo executado sem problemas... Agradeço desde já a atenção de todos... Fernando Faria Mariano
Re: Problemas com compartilhamento NFS
Em Ter, 2006-10-10 às 16:06 -0300, Flamarion Jorge escreveu: Boa tarde, Bom dia 80))) Ambiente compartilhamento nfs no servidor /dados 10.14.26.0/255.255.255.0 a linha acima tem que ser assim: /dados 10.14.26.0/255.255.255.0(rw,sync) para ter certeza que quem montar terá acesso de rw e o sync é só para não ficar o warning perturbando na inicialização do NFS..80) dentro de /dados temos: ../dir1 permissões 770 dono root grupo dir1 ../dir2 permissões 770 dono root grupo dir2 ../dir3 premissões 770 dono root grupo dir3 qual o GID do grupo nos homes dos usuarios foi criado o .gnomerc para forçar a a permissão dos arquivos. umask u=rwx,g=rwx,o=rx Vamos ao problema. se tenho um usuario com os seguintes acessos uid=1031(flamarion) gid=1095(dir1) grupos=1095(dir1),1097(dir2) /dados 10.14.26.0/255.255.255.0/dados 10.14.26.0/255.255.255.0/dados 10.14.26.0/255.255./dados 10.14.26.0/255.255.255.0255.0 teoricamente ele teria acesso de leitura escrita e execução dentro das pastas ../dir1 e ../dir2 Teoricamente ele só terá acesso aos dados SE os UID e GID tanto do servidor quanto das estação FOR O MESMO. veja que o NFS se baseia em todo o princípio de UID e GID e não de nomes Ok destrinchando para não ter dúvidas: o Flamariom que tem UID no desktop dele como: flamarion uid 1031, dir1 1095 dir2 1097 TEM QUE TER EXATAMENTE os mesmos UID e GID no servidor, senão não funciona!! O que acontece é que a pasta ../dir2 aparece com o acesso liberado para o usuario porem o mesmo não consegue ter acesso aos documentos nela contidos, lembrando que todos os documentos da pasta dir2 estão gravados com permissões 770 e o grupo dir2. humm não seria interessante colocar permissão nestas pastas como 2770 e grupo do diretório como dir2 ??? Mas na pasta dir1 que tem as mesmas permissões que a dir2, porem o grupo ser dir1 o usuaio tem acesso normalmente. ok ver acima e seu problema fica resolvido..80) Ja me disseram que com o PAM eu conseguiria resolver o problema, ? PAM ??? o que tem o PAM a ver com permissao de arquivos mas eu acho que com o nfs+nis da pra resolver tambem. sim pois aí toda a Autenticação dos usuários fica centralizada no servidor ( preferencialmente NIS+NFS no mesmo servidor) Até por que eu teria que estudar o PAM e implementar e como ja tenho o nis+nfs funcionando gostaria de saber se tem alguma solução. tem ceretza que o seu NIS está funcionando veja com o NIS vc NÂO CRIA usuários no desktop local. Somente no servidor.80) Creio que fui claro. acho que fui mais claro...80))) caso ainda não funcione, coloque os UID e GID completos na lista para analizarmos. Desculpe as letras em maiusculo, é só para chamar a atenção a estes pontos que são importantes. Atenciosamente. []s -- Flamarion Jorge Escola de Saúde Publica de Minas Gerais Coordenador do Serviço de Informática www.esp.mg.gov.br linuxuser#312816 ___ O Yahoo! est de cara nova. Venha conferir! http://br.yahoo.com Paulo Ricardo Bruck Consultor Linux tel 011 9235-4327 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problemas com compartilhamento NFS
Só completando, um comando q pode ser útil é o id -- Marcos 2006/10/11, [EMAIL PROTECTED] [EMAIL PROTECTED]: Em Ter, 2006-10-10 às 16:06 -0300, Flamarion Jorge escreveu: Boa tarde, Bom dia 80))) [...] Teoricamente ele só terá acesso aos dados SE os UID e GID tanto do servidor quanto das estação FOR O MESMO. veja que o NFS se baseia em todo o princípio de UID e GID e não de nomes Ok destrinchando para não ter dúvidas: o Flamariom que tem UID no desktop dele como: flamarion uid 1031, dir1 1095 dir2 1097 TEM QUE TER EXATAMENTE os mesmos UID e GID no servidor, senão não funciona!!
Problemas com compartilhamento NFS
Boa tarde, Ambiente compartilhamento nfs no servidor /dados 10.14.26.0/255.255.255.0 dentro de /dados temos: ../dir1 permissões 770 dono root grupo dir1 ../dir2 permissões 770 dono root grupo dir2 ../dir3 premissões 770 dono root grupo dir3 nos homes dos usuarios foi criado o .gnomerc para forçar a a permissão dos arquivos. umask u=rwx,g=rwx,o=rx Vamos ao problema. se tenho um usuario com os seguintes acessos uid=1031(flamarion) gid=1095(dir1) grupos=1095(dir1),1097(dir2) teoricamente ele teria acesso de leitura escrita e execução dentro das pastas ../dir1 e ../dir2 O que acontece é que a pasta ../dir2 aparece com o acesso liberado para o usuario porem o mesmo não consegue ter acesso aos documentos nela contidos, lembrando que todos os documentos da pasta dir2 estão gravados com permissões 770 e o grupo dir2. Mas na pasta dir1 que tem as mesmas permissões que a dir2, porem o grupo ser dir1 o usuaio tem acesso normalmente. Ja me disseram que com o PAM eu conseguiria resolver o problema, mas eu acho que com o nfs+nis da pra resolver tambem. Até por que eu teria que estudar o PAM e implementar e como ja tenho o nis+nfs funcionando gostaria de saber se tem alguma solução. Creio que fui claro. Atenciosamente. -- Flamarion Jorge Escola de Saúde Publica de Minas Gerais Coordenador do Serviço de Informática www.esp.mg.gov.br linuxuser#312816 ___ Você quer respostas para suas perguntas? Ou você sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! http://br.answers.yahoo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Problemas com compartilhamento NFS
Boa tarde, Ambiente compartilhamento nfs no servidor /dados 10.14.26.0/255.255.255.0 dentro de /dados temos: ../dir1 permissões 770 dono root grupo dir1 ../dir2 permissões 770 dono root grupo dir2 ../dir3 premissões 770 dono root grupo dir3 nos homes dos usuarios foi criado o .gnomerc para forçar a a permissão dos arquivos. umask u=rwx,g=rwx,o=rx Vamos ao problema. se tenho um usuario com os seguintes acessos uid=1031(flamarion) gid=1095(dir1) grupos=1095(dir1),1097(dir2) teoricamente ele teria acesso de leitura escrita e execução dentro das pastas ../dir1 e ../dir2 O que acontece é que a pasta ../dir2 aparece com o acesso liberado para o usuario porem o mesmo não consegue ter acesso aos documentos nela contidos, lembrando que todos os documentos da pasta dir2 estão gravados com permissões 770 e o grupo dir2. Mas na pasta dir1 que tem as mesmas permissões que a dir2, porem o grupo ser dir1 o usuaio tem acesso normalmente. Ja me disseram que com o PAM eu conseguiria resolver o problema, mas eu acho que com o nfs+nis da pra resolver tambem. Até por que eu teria que estudar o PAM e implementar e como ja tenho o nis+nfs funcionando gostaria de saber se tem alguma solução. Creio que fui claro. Atenciosamente. -- Flamarion Jorge Escola de Saúde Publica de Minas Gerais Coordenador do Serviço de Informática www.esp.mg.gov.br linuxuser#312816 ___ O Yahoo! está de cara nova. Venha conferir! http://br.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sistema travou devido ao compartilhamento NFS
On 4/3/06, Jonathan Meller wrote: Ave! Ave Jonathan, respondi te salutant! :-) O problema é o seguinte: quando temos um compartilhamento NFS estabelecido e a comunicação é interrompida, por uma razão de segurança, o cliente aguarda o restabelecimento da conexão. Enquanto isso, acesso ao diretório /mnt, comandos como df, fuser, etc não funcionam também. Muito bem, qual o procedimento para abortar a conexão NFS sem rebootar??? Nem comandos violentos :) me ajudaram (kill -9, nem modprobe -r -f). On 4/3/06, Anderson Silva wrote: soft If an NFS file operation has a major timeout then report an I/O error to the calling program. The default is to continue retrying NFS file operations indefinitely. hard If an NFS file operation has a major timeout then report server not responding on the console and continue retrying indefinitely. This is the default. Traduzindo a msg do Anderson: Use a opção soft ao montar o compartilhamento NFS que esse travamento não acontecerá mais. Agora respondendo a sua pergunta, nada pode ser feito quando um processo aguarda uma resposta de I/O, tem que esperar mesmo. -- Bruno de Oliveira Schneider http://www.dcc.ufla.br/~bruno/
Sistema travou devido ao compartilhamento NFS
Ave!O problema é o seguinte: quando temos um compartilhamento NFS estabelecido e a comunicação é interrompida, por uma razão de segurança, o cliente aguarda o restabelecimento da conexão. Enquanto isso, acesso ao diretório /mnt, comandos como df, fuser, etc não funcionam também. Muito bem, qual o procedimento para abortar a conexão NFS sem rebootar??? Nem comandos violentos :) me ajudaram (kill -9, nem modprobe -r -f). Até.-- May the Source be with you
Re: Sistema travou devido ao compartilhamento NFS
On 4/3/06, Jonathan Meller [EMAIL PROTECTED] wrote: Ave!O problema é o seguinte: quando temos um compartilhamento NFS estabelecido e a comunicação é interrompida, por uma razão de segurança, o cliente aguarda o restabelecimento da conexão. Enquanto isso, acesso ao diretório /mnt, comandos como df, fuser, etc não funcionam também. Muito bem, qual o procedimento para abortar a conexão NFS sem rebootar??? Nem comandos violentos :) me ajudaram (kill -9, nem modprobe -r -f). soft If an NFS file operation has a major timeout then report an I/O error to the calling program. The default is to continue retrying NFS file operations indefinitely. hard If an NFS file operation has a major timeout then report server not responding on the console and continue retrying indefinitely. This is the default.
