Re: Nfs pierde los enlaces simbolicos mapeados a local
El día 18 de septiembre de 2013 16:30, Santiago José López Borrazás escribió: > El 18/09/13 16:23, KyD escribió: > > (Evitar el HTML, gracias) > >> Lo que este en /tmp se vacia al reiniciar el sistema por norma general. Para >> evitar esto. >> >> Editar el archivo : /etc/default/rcS >> >> y cambia la variable de : >> >> TMPTIME=0 --> TMPTIME=infinite > > No es necesario. A no ser que quieras tener algunos ficheros enmarcados, > para ello, hay que dejar como: > > TMPTIME=7 > > Es lo más recomendable. > > -- > Saludos de Santiago José López Borrazás. > Pofff habéis dado en el clavo chicos ya no me acordaba lo de /tmp ...y su sticky bit Muchas gracias chicos. PD: Al final el pobre nfs no tenía culpa...xDD -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ2aOA8zg5jLDLbKQmBKNjgTv63z+zxm-KzC1=dw9sbm5q2...@mail.gmail.com
Re: Nfs pierde los enlaces simbolicos mapeados a local
El 18/09/13 16:23, KyD escribió: (Evitar el HTML, gracias) > Lo que este en /tmp se vacia al reiniciar el sistema por norma general. Para > evitar esto. > > Editar el archivo : /etc/default/rcS > > y cambia la variable de : > > TMPTIME=0 --> TMPTIME=infinite No es necesario. A no ser que quieras tener algunos ficheros enmarcados, para ello, hay que dejar como: TMPTIME=7 Es lo más recomendable. -- Saludos de Santiago José López Borrazás. signature.asc Description: OpenPGP digital signature
Re: Nfs pierde los enlaces simbolicos mapeados a local
Lo que este en /tmp se vacia al reiniciar el sistema por norma general. Para evitar esto. Editar el archivo : /etc/default/rcS y cambia la variable de : TMPTIME=0 --> TMPTIME=infinite El 18 de septiembre de 2013 08:43, Maykel Franco escribió: > El día 18 de septiembre de 2013 13:28, fernando sainz > escribió: > > El día 18 de septiembre de 2013 12:23, Maykel Franco > > escribió: > >> Hola muy buenas, tenemos 2 apaches que escriben en el mismo fichero > >> via nfs. Antes de nada, está puesto en nfs porque las escrituras son > >> muy pocas, son cuando se realizan ventas, por ejemplo. Cada 5 min > >> aprox y por norma general incluso más, escribe uno de los 2 nodos, > >> dependiendo de en cual se ha realizado la petición de una determinada > >> venta. > >> > >> Antes de que me digáis nada, sé que nfs no se lleva muy bien con > >> lectura y escritura simultáneamente de manera insistente, puesto que > >> no hace bloqueo de fichero, como por ejemplo drbd(que no es lo mismo). > >> > >> Al grano, pongo la situación de 2 apaches en 2 container openvz: > >> > >> - web1 > >> - web2 > >> > >> Añado a la configuración del container para que monte nfs cuando > >> arranque el container web1 y web2, en su correspondiente > >> IDopenvz.mount siguiendo esta guía: > >> > >> > http://www.howtoforge.com/openvz-mounting-host-devices-partitions-directories-in-a-container-with-bind-mounts-debian-ubuntu > >> > >> Lo monta bien y sin problema. Apache escribe el log en local en > >> /tmp/log. El tema es que si queremos tener ese log en comun para que > >> ambos apaches escriban, hacemos un enlace simbolico de tal forma: > >> > >> ln -s /mnt/nfs/log /tmp/ > >> > >> Hasta ahí todo bien, sin embargo si renicias cualquier de los 2, si te > >> vas a su /tmp/ no aparece el enlace simbólico...El montaje de nfs lo > >> realiza openvz(proxmox) en cuanto arrancas el container, > >> evidentemente. Sin embargo no está...Hay que crearlo otra vez...Y ya > >> no sé si es debido a ser nfs el sistema de ficheros o porque monta > >> antes el sistema openvz que nfs y como no lo encuentra lo borra...Pero > >> por normal general y por experiencia, si un enlace simbólico lo creas > >> en local y se borra a lo que apunta ese enlace, se queda el enlace > >> perdido y listo, no se borra. > >> > >> El caso es que lo he solventado añadiendo un servicio /etc/init.d/ que > >> básicamente haga el ln(enlace simbólico) , luego en el runlevel 2, le > >> he puesto para que arranque antes que apache(que por defecto al hace > >> rel update-rc.d me lo ha puesto antes) y ahora sí que > >> funciona...Aunque está "solucionado" me gustaría saber por qué es > >> realmente, y si a alguien le ha pasado. > >> > >> Gracias. > >> > >> Saludos. > >> > >> > > No sé por que te pasa lo de los links, pero para el problema del que > > hablas lo que creo que se hace es mandar los logs a través de syslog. > > > > Mira este enlace o busca apache y syslog en google. > > > > http://www.oreillynet.com/pub/a/sysadmin/2006/10/12/httpd-syslog.html > > > > S2. > > > > > > -- > > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > > Archive: > http://lists.debian.org/cagwrhgpeegtvqjruwh5kxufi3z4qwpscychxecwmymya7...@mail.gmail.com > > > > > Gracias por la respuesta. Y así es como tenemos los demás servicios de > loggin a full, en remoto pero concretametne he comentado que este > servicio que escribe un maximo de 5 min, hay veces que escribe a la > hora por lo general, por eso no lo metimos. Además queríamos tenerlo > así. > > Una cosa es tenerlo en syslog, perfecto pero el problema que comento > es otro. Lo probaré en una máquina normal y corriente, no en un > container y probaré haber. > > Gracias de todas formas. > > Saludos. > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > http://lists.debian.org/caj2aoa_8w7kkupxvj2mphos4s7qtkl9jpkw_pf2ffpdm-ti...@mail.gmail.com > >
Re: Nfs pierde los enlaces simbolicos mapeados a local
El día 18 de septiembre de 2013 13:28, fernando sainz escribió: > El día 18 de septiembre de 2013 12:23, Maykel Franco > escribió: >> Hola muy buenas, tenemos 2 apaches que escriben en el mismo fichero >> via nfs. Antes de nada, está puesto en nfs porque las escrituras son >> muy pocas, son cuando se realizan ventas, por ejemplo. Cada 5 min >> aprox y por norma general incluso más, escribe uno de los 2 nodos, >> dependiendo de en cual se ha realizado la petición de una determinada >> venta. >> >> Antes de que me digáis nada, sé que nfs no se lleva muy bien con >> lectura y escritura simultáneamente de manera insistente, puesto que >> no hace bloqueo de fichero, como por ejemplo drbd(que no es lo mismo). >> >> Al grano, pongo la situación de 2 apaches en 2 container openvz: >> >> - web1 >> - web2 >> >> Añado a la configuración del container para que monte nfs cuando >> arranque el container web1 y web2, en su correspondiente >> IDopenvz.mount siguiendo esta guía: >> >> http://www.howtoforge.com/openvz-mounting-host-devices-partitions-directories-in-a-container-with-bind-mounts-debian-ubuntu >> >> Lo monta bien y sin problema. Apache escribe el log en local en >> /tmp/log. El tema es que si queremos tener ese log en comun para que >> ambos apaches escriban, hacemos un enlace simbolico de tal forma: >> >> ln -s /mnt/nfs/log /tmp/ >> >> Hasta ahí todo bien, sin embargo si renicias cualquier de los 2, si te >> vas a su /tmp/ no aparece el enlace simbólico...El montaje de nfs lo >> realiza openvz(proxmox) en cuanto arrancas el container, >> evidentemente. Sin embargo no está...Hay que crearlo otra vez...Y ya >> no sé si es debido a ser nfs el sistema de ficheros o porque monta >> antes el sistema openvz que nfs y como no lo encuentra lo borra...Pero >> por normal general y por experiencia, si un enlace simbólico lo creas >> en local y se borra a lo que apunta ese enlace, se queda el enlace >> perdido y listo, no se borra. >> >> El caso es que lo he solventado añadiendo un servicio /etc/init.d/ que >> básicamente haga el ln(enlace simbólico) , luego en el runlevel 2, le >> he puesto para que arranque antes que apache(que por defecto al hace >> rel update-rc.d me lo ha puesto antes) y ahora sí que >> funciona...Aunque está "solucionado" me gustaría saber por qué es >> realmente, y si a alguien le ha pasado. >> >> Gracias. >> >> Saludos. >> >> > No sé por que te pasa lo de los links, pero para el problema del que > hablas lo que creo que se hace es mandar los logs a través de syslog. > > Mira este enlace o busca apache y syslog en google. > > http://www.oreillynet.com/pub/a/sysadmin/2006/10/12/httpd-syslog.html > > S2. > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/cagwrhgpeegtvqjruwh5kxufi3z4qwpscychxecwmymya7...@mail.gmail.com > Gracias por la respuesta. Y así es como tenemos los demás servicios de loggin a full, en remoto pero concretametne he comentado que este servicio que escribe un maximo de 5 min, hay veces que escribe a la hora por lo general, por eso no lo metimos. Además queríamos tenerlo así. Una cosa es tenerlo en syslog, perfecto pero el problema que comento es otro. Lo probaré en una máquina normal y corriente, no en un container y probaré haber. Gracias de todas formas. Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj2aoa_8w7kkupxvj2mphos4s7qtkl9jpkw_pf2ffpdm-ti...@mail.gmail.com
Re: Nfs pierde los enlaces simbolicos mapeados a local
El día 18 de septiembre de 2013 12:23, Maykel Franco escribió: > Hola muy buenas, tenemos 2 apaches que escriben en el mismo fichero > via nfs. Antes de nada, está puesto en nfs porque las escrituras son > muy pocas, son cuando se realizan ventas, por ejemplo. Cada 5 min > aprox y por norma general incluso más, escribe uno de los 2 nodos, > dependiendo de en cual se ha realizado la petición de una determinada > venta. > > Antes de que me digáis nada, sé que nfs no se lleva muy bien con > lectura y escritura simultáneamente de manera insistente, puesto que > no hace bloqueo de fichero, como por ejemplo drbd(que no es lo mismo). > > Al grano, pongo la situación de 2 apaches en 2 container openvz: > > - web1 > - web2 > > Añado a la configuración del container para que monte nfs cuando > arranque el container web1 y web2, en su correspondiente > IDopenvz.mount siguiendo esta guía: > > http://www.howtoforge.com/openvz-mounting-host-devices-partitions-directories-in-a-container-with-bind-mounts-debian-ubuntu > > Lo monta bien y sin problema. Apache escribe el log en local en > /tmp/log. El tema es que si queremos tener ese log en comun para que > ambos apaches escriban, hacemos un enlace simbolico de tal forma: > > ln -s /mnt/nfs/log /tmp/ > > Hasta ahí todo bien, sin embargo si renicias cualquier de los 2, si te > vas a su /tmp/ no aparece el enlace simbólico...El montaje de nfs lo > realiza openvz(proxmox) en cuanto arrancas el container, > evidentemente. Sin embargo no está...Hay que crearlo otra vez...Y ya > no sé si es debido a ser nfs el sistema de ficheros o porque monta > antes el sistema openvz que nfs y como no lo encuentra lo borra...Pero > por normal general y por experiencia, si un enlace simbólico lo creas > en local y se borra a lo que apunta ese enlace, se queda el enlace > perdido y listo, no se borra. > > El caso es que lo he solventado añadiendo un servicio /etc/init.d/ que > básicamente haga el ln(enlace simbólico) , luego en el runlevel 2, le > he puesto para que arranque antes que apache(que por defecto al hace > rel update-rc.d me lo ha puesto antes) y ahora sí que > funciona...Aunque está "solucionado" me gustaría saber por qué es > realmente, y si a alguien le ha pasado. > > Gracias. > > Saludos. > > No sé por que te pasa lo de los links, pero para el problema del que hablas lo que creo que se hace es mandar los logs a través de syslog. Mira este enlace o busca apache y syslog en google. http://www.oreillynet.com/pub/a/sysadmin/2006/10/12/httpd-syslog.html S2. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGw=rHgpEEG=tvqjruwh5kxufi3z4qwpscychxecwmymya7...@mail.gmail.com
Nfs pierde los enlaces simbolicos mapeados a local
Hola muy buenas, tenemos 2 apaches que escriben en el mismo fichero via nfs. Antes de nada, está puesto en nfs porque las escrituras son muy pocas, son cuando se realizan ventas, por ejemplo. Cada 5 min aprox y por norma general incluso más, escribe uno de los 2 nodos, dependiendo de en cual se ha realizado la petición de una determinada venta. Antes de que me digáis nada, sé que nfs no se lleva muy bien con lectura y escritura simultáneamente de manera insistente, puesto que no hace bloqueo de fichero, como por ejemplo drbd(que no es lo mismo). Al grano, pongo la situación de 2 apaches en 2 container openvz: - web1 - web2 Añado a la configuración del container para que monte nfs cuando arranque el container web1 y web2, en su correspondiente IDopenvz.mount siguiendo esta guía: http://www.howtoforge.com/openvz-mounting-host-devices-partitions-directories-in-a-container-with-bind-mounts-debian-ubuntu Lo monta bien y sin problema. Apache escribe el log en local en /tmp/log. El tema es que si queremos tener ese log en comun para que ambos apaches escriban, hacemos un enlace simbolico de tal forma: ln -s /mnt/nfs/log /tmp/ Hasta ahí todo bien, sin embargo si renicias cualquier de los 2, si te vas a su /tmp/ no aparece el enlace simbólico...El montaje de nfs lo realiza openvz(proxmox) en cuanto arrancas el container, evidentemente. Sin embargo no está...Hay que crearlo otra vez...Y ya no sé si es debido a ser nfs el sistema de ficheros o porque monta antes el sistema openvz que nfs y como no lo encuentra lo borra...Pero por normal general y por experiencia, si un enlace simbólico lo creas en local y se borra a lo que apunta ese enlace, se queda el enlace perdido y listo, no se borra. El caso es que lo he solventado añadiendo un servicio /etc/init.d/ que básicamente haga el ln(enlace simbólico) , luego en el runlevel 2, le he puesto para que arranque antes que apache(que por defecto al hace rel update-rc.d me lo ha puesto antes) y ahora sí que funciona...Aunque está "solucionado" me gustaría saber por qué es realmente, y si a alguien le ha pasado. Gracias. Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj2aoa_fnjes52bhukx19fuatjwj08bpy3xwu_6t2wngku9...@mail.gmail.com
Re: Enlaces simbolicos
On Tue, 2009-04-28 at 10:59 +1930, Roberto De Oliveira wrote: > Quizás es porque el ambiente gráfico no utiliza el .bashrc (este sólo > lo utiliza bash), si quieres que el ambiente gráfico tenga una > variable definida, puedes colocarla en el archivo /etc/environment, > otra alternativa podría ser en vez de hacer un enlace simbólico, hacer > un .desktop. > Hola Roberto, Gracias por responder. Es cierto que haber incluido la ruta dentro de environment hubiera incluido correctamente la ruta para el gestor de pantalla pero yo lo quería sólo para ejecuciones locales (para mi usuario). El script $HOME/.profile me sirvió. Con ejecutar la acción "export" e incluir la ruta donde están ubicadas las aplicaciones que quería ejecutar basto. La información la obtuve de https://help.ubuntu.com/community/EnvironmentVariables Un saludo, Bruno -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Enlaces simbolicos
bruno escribió: Hola, Hace unos días pregunte aquí acerca de la ejecución de ciertas aplicaciones desde el escritorio. Resulta que instalé varias aplicaciones en el directorio /opt/, entre ellas gnat-gps, eclipse y jre (no apt-get) y no arrancaban desde enlaces simbólicos en el escritorio. Alguien me contesto que para arrancar estas aplicaciones desde el escritorio debía crear un enlace simbólico de los ejecutables en el directorio /usr/bin. Funcionó. Logré arrancar todas las aplicaciones. Ahora me pregunto porque debo hacer esto si dentro del archivo bashrc de mi usuario ya están las rutas de los archivos binarios para que arranquen los programas. Ahora resulta que para poder compilar en Ada con Gnat tengo que ir creando enlaces simbólicos de la aplicaciones referidas al proceso de compilación y ejecución de estos programas en /usr/bin. Por ejemplo gnat, gnatmake o gcc. ¿Porque ocurre esto? ¿Pórque no arrancan los comandos si ya están las rutas adecuadas en mi $PATH? ¿Cómo puedo añadir un enlace simbólico de todas los comandos que existen en /opt/gnat/bin en /usr/bin con una sola orden? Gracias. Un saludo, Desde la consola qué dice echo $PATH están allí tus directorios con los binarios Si pruebas invocarlos desde la consola puedes ejecutarlos? Fijate que en el Desktop los archivos que invocan a las aplicaciones no suelen ser enlaces simbólicos sino archivos de configuración del escritorio. Además puedes probar si haciendo alt+F2 y escribiendo el nombre de la aplicación se ejecuta en modo gráfico. Saludos -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Enlaces simbolicos
Hola, Hace unos días pregunte aquí acerca de la ejecución de ciertas aplicaciones desde el escritorio. Resulta que instalé varias aplicaciones en el directorio /opt/, entre ellas gnat-gps, eclipse y jre (no apt-get) y no arrancaban desde enlaces simbólicos en el escritorio. Alguien me contesto que para arrancar estas aplicaciones desde el escritorio debía crear un enlace simbólico de los ejecutables en el directorio /usr/bin. Funcionó. Logré arrancar todas las aplicaciones. Ahora me pregunto porque debo hacer esto si dentro del archivo bashrc de mi usuario ya están las rutas de los archivos binarios para que arranquen los programas. Ahora resulta que para poder compilar en Ada con Gnat tengo que ir creando enlaces simbólicos de la aplicaciones referidas al proceso de compilación y ejecución de estos programas en /usr/bin. Por ejemplo gnat, gnatmake o gcc. ¿Porque ocurre esto? ¿Pórque no arrancan los comandos si ya están las rutas adecuadas en mi $PATH? ¿Cómo puedo añadir un enlace simbólico de todas los comandos que existen en /opt/gnat/bin en /usr/bin con una sola orden? Gracias. Un saludo, -- Bruno Jesus Mendoza Guedes +34 690 809 949 brunomend...@xxxgmail.com (quitar XXX) | | + \ \\.G_.*=. `( '/.\| .>' (_--. _=/d ,^\ ~~ \)-' ' / | ' ' a:f -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Enlaces simbolicos rotos tras compilar kernel
Hola compañeros: He compilado mi primer kernel y pareciera que todo funciona bien, exepto los enlaces simbólicos que aparecen como rotos, y también mis particiones de W$ no las encuentra. Quisiera saber si me pueden dar alguna orientación porque busco en google "enlaces simbolicos rotos" pero no me aparecen relacionados con compilar un nuevo kernel. El kernel que estoy utilizando es el 2.6.9 preparcheado para utilizarlo con RealTime Linux. Saludos y muchas gracias. __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.com.mx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Error en enlaces simbolicos en pag. del man
Fernando wrote:
>
> > > Hola:
> > >
> > > Curioseando en la maquina del Compaq Test Drive Program he encontrado
> > > esto:
> > >
> > > ls -la /usr/man/man1/csh.1.gz
> > > lrwxrwxrwx1 root root 26 Sep 11 1999
> > > /usr/man/man1/csh.1.gz -> /etc/alternatives/csh.1.gz
> > >
> > > ls -la /etc/alternatives/csh.1.gz
> > > lrwxrwxrwx1 root root 23 Sep 11 1999
> > > /etc/alternatives/csh.1.gz -> /usr/man/man1/tcsh.1.gz
>
> >
> > No existe /usr/man/man1/tcsh.1.gz
> > esta en /usr/share/man/man1/tcsh.1.gz
> >
>
> Hay mas:
>
> /usr/man> find . -name "*" -follow -exec grep {} \;
>
> find: ./man1/csh.1.gz: No such file or directory
> find: ./man1/pstogif.1.gz: No such file or directory
> find: ./man1/guile.1.gz: No such file or directory
> find: ./man1/expectk.1.gz: No such file or directory
>
( Los enlaces simbólicos a estas páginas estan mal )
Yo no tengo Potato, no se si esto pasa sólo en esa máquina
o es un error de la nueva distribución.
Puede alguien confirmarmelo.
Saludos.
--
Fernando.
{:-{D>
"Hackers do it with fewer instructions."
