EVS 1.- Establecimiento del Alcance del Sistema
EVS 1.1.- Estudio de la Solicitud
Requisitos
El sistema debe ser multiempresa, es decir, permitirá la creación de múltiples empresas, cada una de ellas a su vez podrá contar con múltiples agencias o sucursales, las cuales a su vez podrán contar con múltiples departamentos y cada departamento con múltiples puestos o mesas. Cada mesa podrá estar asignada a varios usuarios, para permitir, por ejemplo, su utilización compartida o por turnos.
Se prevé un sistema jerárquico de 4 ó 5 niveles, aunque es posible que para agencias pequeñas, sea suficiente con 2 ó 3 niveles, por lo que el número de niveles y su descripción será totalmente flexible y a elegir por el usuario responsable. Cada nivel corresponderá con un rol, que se asignará a un grupo de usuarios; cada grupo de usuarios estará compuesto por uno o más usuarios. Un usuario puede pertenecer a varios grupos. A cada usuario le corresponderá el rol o roles del grupo o grupos a los que pertenezca.
Se definirán roles y grupos funcionales, es decir a cada función del sistema se le asignara un rol, de forma que sólo los usuarios con dicho rol podrán interactuar con la función. También se podrá establecer la forma de interacción con la función (de menor a mayor permiso): consulta, modificación, alta y baja. De esta forma se establecerán los permisos de acceso a las funciones por parte de los usuarios.
El sistema debe ser multiusuario, es decir, podrá ser usado simultáneamente por uno o más usuarios. Se preverán los correspondientes mecanismos de bloqueos/desbloqueo de forma que se eviten conflictos de concurrencia. Se tendrá en especial consideración los mecanismos que permitan compartir la información del sistema: clientes, proveedores, etc., pero siempre respetando los permisos de acceso.
La concepción del sistema es la de una gestión de expedientes, por lo que se pondrá especial énfasis en la modularidad de esta función, ya que servirá de base para el desarrollo de otros proyectos. Los expedientes van a contener mucha información y documentos heterogéneos: datos en base de datos, correos, documentos de texto, imágenes, fax, audio, etc. Se integrarán en el sistema los visores de cada tipo de documento y si fuese necesario, se realizará una normalización o conversión previa a un formato único. Los documentos de texto se indexarán para permitir búsquedas en su contenido.
Como norma, no debe ser necesario abandonar el sistema para realizar cualquier acción del flujo de trabajo de la agencia, es decir, que se procurará integrar en el sistema las herramientas o componentes necesarios para realizar todas las acciones.
La arquitectura del sistema corresponderá con un modelo cliente/servidor en web, ya que esto permitirá un despliegue y mantenimiento más sencillo. También facilitará la utilización del sistema por los usuarios, independientemente de su localización geográfica, y según los casos, posibilitará la utilización de dispositivos móviles a la hora de realizar algunas acciones del flujo de trabajo (confirmaciones, pedidos, presupuestos, etc.) a perfiles de usuarios comerciales itinerantes, que hagan visita a proveedores y/o clientes. Se podrá acceder al sistema vía Internet. Se prevé que el desarrollo de esta parte del sistema se realice en PHP.
El acceso al sistema debe estar protegido por contraseña, pero una vez validado el usuario no se le volverá a solicitar su identificación para el resto de funcionalidades, es decir, se proveerá de un mecanismo de login único.
Algunas acciones requieren la utilización de dispositivos en o desde la máquina del usuario, a las que no se tendrá acceso desde el sistema en web, ya que técnicamente no se tiene control de los dispositivos locales en una aplicación web; en estos casos se dispondrán de aplicaciones locales que se comunicarán con el sistema, vía ficheros de intercambio, correos o cualquier otro mecanismo. Se prevé que el desarrollo de esta parte del sistema se realice en Gambas. Dentro de este tipo de acciones caben destacar las relacionadas con la utilización de telefonía, tanto fija como móvil, que deberán ser automatizadas en la medida de lo posible, permitiendo la marcación desde la agenda/contactos, reconocimiento de llamada, lo que desplegará la información disponible en el sistema relacionada con dicho número (expedientes del cliente, proveedor, etc.). Sería deseable que también se pudieran grabar las conversaciones, a efectos de control y de respaldo. También se automatizará la utilización del fax, de forma que tanto la generación electrónica, envío y recepción estén integrados en el sistema. Otro dispositivo a integrar será el escaner; los documentos escaneados se integrarán en el sistema de forma automática, sin más intervención del usuario que la imprescindible.
El sistema debe ser muy eficiente en la captura de datos. Por ejemplo, en las páginas de los proveedores para realizar las reservas se introducen los datos del cliente y de la reserva (fechas, nombre de hoteles, etc., es decir los datos para describir la reserva). Estos datos deben ser capturados y almacenados temporalmente hasta que se incorporen al expediente. De esta forma se evita la introducción reiterada de la misma información, aunque sean sistemas distintos, con el consiguiente ahorro de tiempo y esfuerzo, a la vez que se evitan errores. De la misma forma, las páginas que se deban rellenar con datos ya incorporados en el sistema o que se puedan calcular a partir de ellos, por ejemplo, los datos para realizar transferencias en las que se deba indicar el importe y la referencia (habitualmente el número de localizador de la reserva), el rellenado debe hacerse de forma automática. Este caso es especialmente sensible a los errores ya que indicar un importe o referencia erróneos puede tener un gran impacto en tiempo, esfuerzo (anulación/modificación) y dinero (gastos de cancelación, etc.).
Toda la documentación que se deba entregar al cliente debe poder ser generada de forma automática: recibos, facturas, etc.
Toda la documentación generada, recibida, capturada, enviada, entregada, etc., se incorporará automáticamente al expediente, donde estará disponible para su consulta.
La documentación que se reciba de los proveedores servirá para actualizar o disparar los eventos correspondientes que actualicen el estado de los expedientes afectados. Por ejemplo, la recepción de facturas, bonos, etc.
Las acciones que se realicen con las entidades financieras (transferencias, pagos, ingresos, etc.) también deben poderse asignar a los expedientes, disparando los eventos o generando la documentación que corresponda. Por ejemplo, el pago de una reserva debe actualizar el saldo pendiente de pagar al proveedor y en el caso de que el pendiente sea cero, generar la correspondiente factura de comisiones, que a su vez actualizará la contabilidad o estado de cuentas. También se generará, si ha lugar, el documento de confirmación de pago al proveedor, en el formato que éste solicite (fax, mail, etc.) y se procederá a su envío, dejando constancia del mismo y actualizando también el estado del expediente.
En esta fase no se requiere el desarrollo de una contabilidad oficial integrada, con generación de apuntes contables, etc., aunque el sistema debe estar preparado para abordar este desarrollo en un futuro. Sí se generará un estado de cuentas de gastos e ingresos, que sin ser una contabilidad oficial, permita al gestor tener una idea del estado y evolución del negocio.
26/11/2009
expeges. EVS: Estudio de Viabilidad del Sistema
EVS 1.- Establecimiento del Alcance del Sistema
EVS 1.1.- Estudio de la Solicitud
Descripción
La solicitud consiste en disponer de un sistema automatizado que facilite y/o soporte todas las tareas que se realizan en una agencia de viajes. En general, todas las tareas o procesos manuales deben poder ser automatizados, con el objeto de que siempre quede constancia de su realización y por quién, a efectos de documentación y seguimiento. Además, como objetivo adicional de la automatización, se pretende lograr la normalización y descripción de todos los procesos, lo cual facilite la obtención de una certificación de la calidad de la gestión ISO 9001.
El espíritu del sistema debe ser el de facilitar la labor al usuario, evitando la introducción de datos innecesarios o duplicar las entradas de datos, utilizar búsquedas y ayudas automáticas para la selección de datos, disponer de la mayor información disponible al alcance del usuario en su relación con clientes o proveedores. El sistema debe ser amigable y estar orientado a generar eventos que faciliten el recordatorio de citas o acciones por parte del usuario, en general debe ser el sistema el que “recuerde” las acciones a realizar y se las presente al usuario asignado para que las cumplimente. En este sentido, no se desea un sistema tradicional con un árbol de funciones, sino que los formularios, pantallas o informes aparezcan y se presenten al usuario según las necesidades del flujo de trabajo. Se primara, por encima de todo, la eficiencia de los procesos.
Restricciones
El sistema debe ser lo más económico posible, tanto en su desarrollo como en su puesta en producción. Para ello, se debe contar con que todo, o al menos su mayor parte, el software necesario debe ser gratuito o de licencia libre: sistema operativo, herramientas de desarrollo, servidor web, base de datos, componentes, etc. Tampoco se deben requerir elementos hardware exóticos ni de elevado presupuesto.
Las soluciones técnicas deben estar basadas, siempre que sea posible, en componentes ya desarrollados, contrastados y fiables.
Se evitará la utilización de componentes software que requieran de una licencia. En principio no está previsto que el desarrollo se comercialice, aunque sería posible la utilización por terceros en un formato de “pago por uso”. También sería posible una implantación gratuita con el código desarrollado ofuscado y el establecimiento de un contrato de mantenimiento.
Objetivos del EVS
Como la justificación económica es obvia, el riesgo técnico bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable, no es necesario profundizar en el estudio de viabilidad del sistema, analizando posibles alternativas y realizando una valoración y evaluación de las mismas, sino que éste se orientará a la especificación de requisitos, descripción del nuevo sistema y planificación.
EVS 1.1.- Estudio de la Solicitud
Descripción
La solicitud consiste en disponer de un sistema automatizado que facilite y/o soporte todas las tareas que se realizan en una agencia de viajes. En general, todas las tareas o procesos manuales deben poder ser automatizados, con el objeto de que siempre quede constancia de su realización y por quién, a efectos de documentación y seguimiento. Además, como objetivo adicional de la automatización, se pretende lograr la normalización y descripción de todos los procesos, lo cual facilite la obtención de una certificación de la calidad de la gestión ISO 9001.
El espíritu del sistema debe ser el de facilitar la labor al usuario, evitando la introducción de datos innecesarios o duplicar las entradas de datos, utilizar búsquedas y ayudas automáticas para la selección de datos, disponer de la mayor información disponible al alcance del usuario en su relación con clientes o proveedores. El sistema debe ser amigable y estar orientado a generar eventos que faciliten el recordatorio de citas o acciones por parte del usuario, en general debe ser el sistema el que “recuerde” las acciones a realizar y se las presente al usuario asignado para que las cumplimente. En este sentido, no se desea un sistema tradicional con un árbol de funciones, sino que los formularios, pantallas o informes aparezcan y se presenten al usuario según las necesidades del flujo de trabajo. Se primara, por encima de todo, la eficiencia de los procesos.
Restricciones
El sistema debe ser lo más económico posible, tanto en su desarrollo como en su puesta en producción. Para ello, se debe contar con que todo, o al menos su mayor parte, el software necesario debe ser gratuito o de licencia libre: sistema operativo, herramientas de desarrollo, servidor web, base de datos, componentes, etc. Tampoco se deben requerir elementos hardware exóticos ni de elevado presupuesto.
Las soluciones técnicas deben estar basadas, siempre que sea posible, en componentes ya desarrollados, contrastados y fiables.
Se evitará la utilización de componentes software que requieran de una licencia. En principio no está previsto que el desarrollo se comercialice, aunque sería posible la utilización por terceros en un formato de “pago por uso”. También sería posible una implantación gratuita con el código desarrollado ofuscado y el establecimiento de un contrato de mantenimiento.
Objetivos del EVS
Como la justificación económica es obvia, el riesgo técnico bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable, no es necesario profundizar en el estudio de viabilidad del sistema, analizando posibles alternativas y realizando una valoración y evaluación de las mismas, sino que éste se orientará a la especificación de requisitos, descripción del nuevo sistema y planificación.
Preparando el entorno
Como un paso más, he instalado un servidor de mail en web, que se podrá embeber en la aplicación. Para ello, he elegido AfterLogic (http://www.afterlogic.com/products/webmail-lite), es muy sencillo de instalar, ya que está escrito en PHP y no se necesita compilar nada. Los correos se guardan en MySQL. Además, incluye una clase PHP para poder integrarse dentro de un iframe y recibir el usuario y contraseña desde otra aplicación PHP, con el objeto de implementar un login único. Emplea AJAX para recargar las páginas. Su aspecto es muy claro y de momento funciona muy bien.
22/11/2009
Preparando el entorno
Después de trastear un poco con Quanta +, no he podido configurarlo bien, además, no he podido ejecutar PHP desde el entorno de desarrollo y mucho menos el debugger de PHP, así que voy a probar otro entorno: eclipse (http://www.eclipse.org/pdt/). Es gratuito y viene con unas extensiones especiales para PHP. También puede disponer de un debugger de PHP (http://www.zend.com/community/pdt?ecl=EclipseZend). Es muy fácil de instalar y configurar, tanto el entorno como el servidor (zend server está basado en apache) para el debugger. He hecho unas pruebas y me parece muy cómodo y el debugger funciona bien.
20/11/2009
Preparando el entorno
Instalación y configuración de Quanta +.
En OpenSuse 11.1 ya viene un paquete de Quanta, se instala, pero cuando se ejecuta Quanta se quedan unas extensiones que no son alcanzables: KFileReplace, KXSLDbg, KimageMapEditor y KLinkStatus. Ni que decir tiene que el entorno es Gnome y no KDE, que es el entorno para el que está pensado Quanta. Además, si se intentan instalar las extensiones, dan un error, ya que necesitan una versión superior de Kdebase4-runtime. Se pueden descargar e instalar todos esos paquetes desde el buscador de software de OpenSuse (http://software.opensuse.org/search). Después hay que configurar Quanta para que encuentre los paquetes (Preferencias → Configurar extensiones), poniendo la ruta y el nombre del paquete, por ejemplo, para KfileReplace la ruta es “/usr/lib/kde4” y el fichero “libkfilereplacepart.so”.
Una vez todo instalado y configurado, se da a la ayuda (F1) y sale un error, ya que al parecer el fichero de la ayuda en español tiene un XML mal construido. Se puede corregir cambiando la carpeta de la ayuda en español (/opt/kde3/share/doc/HTML/es/quanta) por la que está en inglés (/opt/kde3/share/doc/HTML/en/quanta), aunque la ayuda aparecerá en inglés.
En OpenSuse 11.1 ya viene un paquete de Quanta, se instala, pero cuando se ejecuta Quanta se quedan unas extensiones que no son alcanzables: KFileReplace, KXSLDbg, KimageMapEditor y KLinkStatus. Ni que decir tiene que el entorno es Gnome y no KDE, que es el entorno para el que está pensado Quanta. Además, si se intentan instalar las extensiones, dan un error, ya que necesitan una versión superior de Kdebase4-runtime. Se pueden descargar e instalar todos esos paquetes desde el buscador de software de OpenSuse (http://software.opensuse.org/search). Después hay que configurar Quanta para que encuentre los paquetes (Preferencias → Configurar extensiones), poniendo la ruta y el nombre del paquete, por ejemplo, para KfileReplace la ruta es “/usr/lib/kde4” y el fichero “libkfilereplacepart.so”.
Una vez todo instalado y configurado, se da a la ayuda (F1) y sale un error, ya que al parecer el fichero de la ayuda en español tiene un XML mal construido. Se puede corregir cambiando la carpeta de la ayuda en español (/opt/kde3/share/doc/HTML/es/quanta) por la que está en inglés (/opt/kde3/share/doc/HTML/en/quanta), aunque la ayuda aparecerá en inglés.
19/11/2009
Pruebas de viabilidad y preparando el entorno
Hoy le ha tocado el turno al mail.
En el proyecto va a ser fundamental la utilización de un programa integrado de mail en web, tipo squirrelmail (http://squirrelmail.org/); es decir, poder enviar y recibir mail desde una página PHP. La recepción de mail en PHP no es complicada: función imap_open(). Sin embargo para enviar mails, ya es otro cantar: la máquina del servidor HTTP y que ejecuta el PHP también debe tener un servidor de correo activo y configurado correctamente para que la función mail() de PHP sea operativa. Yo estoy utilizando "postfix/sendmail" como servidor de correo.
Pese a que ya había configurado la máquina de producción para enviar mails desde PHP con postfix/sendmail, al configurar la máquina de desarrollo me he tenido que "releer" los manuales. El principal problema es que se trata de una máquina sin ip fija. Estos son los pasos que he dado:
1.- Configurar el Agente de transferencia de medios:
Desde Yast -> Agente de transferencia de medios; elegir "Estándar"; elegir "Permanente"; poner el servidor de correo saliente (smtp) que tengáis con vuestro operador (tipo "smtp.dominio.com") correspondiente a vuestra cuenta de correo; Pulsar botón "Autenticación"; Escribir el usuario y la contraseña de la cuenta de correo; pulsar aceptar hasta finalizar.
2.- Actualizar el /etc/php5/apache2/php.ini para que sepa dónde está el ejecutable del sendmail:
sendmail_path = "/usr/sbin/sendmail -i -t"
3.- Configurar /etc/postfix/main.cf
Es muy largo, pero las líneas claves son (cambiar NOMBREHOST por el nombre de la máquina y DOMINIO por el nombre del dominio de la cuenta de correo):
readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES
inet_protocols = all
biff = no
mail_spool_directory = /var/mail
canonical_maps = hash:/etc/postfix/canonical
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_alias_domains = hash:/etc/postfix/virtual
relocated_maps = hash:/etc/postfix/relocated
transport_maps = hash:/etc/postfix/transport
sender_canonical_maps = hash:/etc/postfix/sender_canonical
masquerade_exceptions = root
masquerade_classes = envelope_sender, header_sender, header_recipient
myhostname = NOMBREHOST.site
myorigin = NOMBREHOST.site
delay_warning_time = 1h
message_strip_characters = \0
program_directory = /usr/lib/postfix
inet_interfaces = all
masquerade_domains = DOMINIO.com
mydestination = $myhostname, localhost.$mydomain
defer_transports =
mynetworks_style = subnet
disable_dns_lookups = no
relayhost = smtp.DOMINIO.com
mailbox_command =
mailbox_transport =
strict_8bitmime = no
disable_mime_output_conversion = no
smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_client_restrictions =
smtpd_helo_required = no
smtpd_helo_restrictions =
strict_rfc821_envelopes = no
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtpd_sasl_auth_enable = no
smtpd_use_tls = no
smtp_use_tls = no
alias_maps = hash:/etc/aliases
mailbox_size_limit = 0
message_size_limit = 10240000
smtp_generic_maps = hash:/etc/postfix/generic
4.- Modificar /etc/postfix/generic para poner los "alias" a los usuarios de correo por defecto. Añadir las siguientes líneas (en vez de usuario@dominio.com poner la dirección de mail que va a enviar los correos y cambiar NOMBREHOST por el nombre de la máquina):
wwwrun@NOMBREHOST.site usuario@dominio.com
root@NOMBREHOST.site usuario@dominio.com
5.- Para actualizar la lista de alias genericos, ejecutar en el terminal de comandos:
# postmap /etc/postfix/generic
6.- Parar y arrancar postfix:
# postfix stop
# postfix start
7.- Parar y arrancar apache:
# /etc/init.d/apache2 stop
# /etc/init.d/apache2 start
y ¡ya está!.
En el proyecto va a ser fundamental la utilización de un programa integrado de mail en web, tipo squirrelmail (http://squirrelmail.org/); es decir, poder enviar y recibir mail desde una página PHP. La recepción de mail en PHP no es complicada: función imap_open(). Sin embargo para enviar mails, ya es otro cantar: la máquina del servidor HTTP y que ejecuta el PHP también debe tener un servidor de correo activo y configurado correctamente para que la función mail() de PHP sea operativa. Yo estoy utilizando "postfix/sendmail" como servidor de correo.
Pese a que ya había configurado la máquina de producción para enviar mails desde PHP con postfix/sendmail, al configurar la máquina de desarrollo me he tenido que "releer" los manuales. El principal problema es que se trata de una máquina sin ip fija. Estos son los pasos que he dado:
1.- Configurar el Agente de transferencia de medios:
Desde Yast -> Agente de transferencia de medios; elegir "Estándar"; elegir "Permanente"; poner el servidor de correo saliente (smtp) que tengáis con vuestro operador (tipo "smtp.dominio.com") correspondiente a vuestra cuenta de correo; Pulsar botón "Autenticación"; Escribir el usuario y la contraseña de la cuenta de correo; pulsar aceptar hasta finalizar.
2.- Actualizar el /etc/php5/apache2/php.ini para que sepa dónde está el ejecutable del sendmail:
sendmail_path = "/usr/sbin/sendmail -i -t"
3.- Configurar /etc/postfix/main.cf
Es muy largo, pero las líneas claves son (cambiar NOMBREHOST por el nombre de la máquina y DOMINIO por el nombre del dominio de la cuenta de correo):
readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES
inet_protocols = all
biff = no
mail_spool_directory = /var/mail
canonical_maps = hash:/etc/postfix/canonical
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_alias_domains = hash:/etc/postfix/virtual
relocated_maps = hash:/etc/postfix/relocated
transport_maps = hash:/etc/postfix/transport
sender_canonical_maps = hash:/etc/postfix/sender_canonical
masquerade_exceptions = root
masquerade_classes = envelope_sender, header_sender, header_recipient
myhostname = NOMBREHOST.site
myorigin = NOMBREHOST.site
delay_warning_time = 1h
message_strip_characters = \0
program_directory = /usr/lib/postfix
inet_interfaces = all
masquerade_domains = DOMINIO.com
mydestination = $myhostname, localhost.$mydomain
defer_transports =
mynetworks_style = subnet
disable_dns_lookups = no
relayhost = smtp.DOMINIO.com
mailbox_command =
mailbox_transport =
strict_8bitmime = no
disable_mime_output_conversion = no
smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_client_restrictions =
smtpd_helo_required = no
smtpd_helo_restrictions =
strict_rfc821_envelopes = no
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtpd_sasl_auth_enable = no
smtpd_use_tls = no
smtp_use_tls = no
alias_maps = hash:/etc/aliases
mailbox_size_limit = 0
message_size_limit = 10240000
smtp_generic_maps = hash:/etc/postfix/generic
4.- Modificar /etc/postfix/generic para poner los "alias" a los usuarios de correo por defecto. Añadir las siguientes líneas (en vez de usuario@dominio.com poner la dirección de mail que va a enviar los correos y cambiar NOMBREHOST por el nombre de la máquina):
wwwrun@NOMBREHOST.site usuario@dominio.com
root@NOMBREHOST.site usuario@dominio.com
5.- Para actualizar la lista de alias genericos, ejecutar en el terminal de comandos:
# postmap /etc/postfix/generic
6.- Parar y arrancar postfix:
# postfix stop
# postfix start
7.- Parar y arrancar apache:
# /etc/init.d/apache2 stop
# /etc/init.d/apache2 start
y ¡ya está!.
17/11/2009
Pruebas de viabilidad y preparando el entorno.
Brrr. He intentado configurar el servidor Samba de la máquina de desarrollo (linux02) para conectarla a la red de Microsoft y lo he conseguido a medias. Después de mucho toquitear Samba, he dado con una configuración medio funcional: Todas las máquinas se "ven", pero la máquina Windows Vista (windows01) sólo puede escribir en la de producción (linux01). Las máquinas Linux no "ven" las carpetas de Windows. Está claro que es un problema de permisos y de crear los usuarios de Samba correctos, pero hoy no me ha alcanzado para "descubrir" el truco. El "atajo" ha consistido en copiar a linux01 los archivos que quiero de windows01 y desde ahí traerlos a linux02. Espero dar con una solución más "elegante".
Curioso, estaba viendo el fichero de configuración de Samba para incluirlo aquí, y me he dado cuenta de que no había creado los usuarios de Samba:
# smbpasswd -a /* cambiar la contraseña de root
# ...
# smbpasswd -a nombreusuario /* dar de alta y poner contraseña a nombreusuario
#...
El fichero /etc/Samba/smbpasswd debería quedar:
#...
root:0:...
nombreusuario:1000:...
Mi "nombreusuario" es el mismo que el usuario administrador de Windows. Además, he modificado los permisos del directorio compartido en linux02 para que cualquiera del grupo tenga control total del directorio. Los usuarios de Samba también están creados como usuarios de Linux y pertenecen al grupo con permisos sobre el directorio a compartir.
El fichero de configuración de Samba en /etc/Samba/smb.conf
# smb.conf is the main Samba configuration file. You find a full commented
# version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the
# samba-doc package is installed.
# Date: 2008-12-03
[global]
workgroup = WRG
security = user
usershare allow guest = No
add machine script = /usr/sbin/useradd -c Machine -d /var/lib/nobody -s /bin/false %m$
domain logons = No
domain master = No
passdb backend = smbpasswd
wins support = No
wins server =
[htdocs]
comment = web portatil
path = /tmp/compartido
read only = No
browseable = Yes
guest ok = Yes
No olvidar de escribir los nombres e ip's de las máquinas de la red en "Yast -> Nombres de equipo".
De momento ya puedo escribir en las máquinas Linux desde Windows, pero éstas siguen sin ver las carpetas compartidas en Windows.
Curioso, estaba viendo el fichero de configuración de Samba para incluirlo aquí, y me he dado cuenta de que no había creado los usuarios de Samba:
# smbpasswd -a /* cambiar la contraseña de root
# ...
# smbpasswd -a nombreusuario /* dar de alta y poner contraseña a nombreusuario
#...
El fichero /etc/Samba/smbpasswd debería quedar:
#...
root:0:...
nombreusuario:1000:...
Mi "nombreusuario" es el mismo que el usuario administrador de Windows. Además, he modificado los permisos del directorio compartido en linux02 para que cualquiera del grupo tenga control total del directorio. Los usuarios de Samba también están creados como usuarios de Linux y pertenecen al grupo con permisos sobre el directorio a compartir.
El fichero de configuración de Samba en /etc/Samba/smb.conf
# smb.conf is the main Samba configuration file. You find a full commented
# version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the
# samba-doc package is installed.
# Date: 2008-12-03
[global]
workgroup = WRG
security = user
usershare allow guest = No
add machine script = /usr/sbin/useradd -c Machine -d /var/lib/nobody -s /bin/false %m$
domain logons = No
domain master = No
passdb backend = smbpasswd
wins support = No
wins server =
[htdocs]
comment = web portatil
path = /tmp/compartido
read only = No
browseable = Yes
guest ok = Yes
No olvidar de escribir los nombres e ip's de las máquinas de la red en "Yast -> Nombres de equipo".
De momento ya puedo escribir en las máquinas Linux desde Windows, pero éstas siguen sin ver las carpetas compartidas en Windows.
Suscribirse a:
Entradas (Atom)
