X-Git-Url: https://git.llucax.com/software/pymin.git/blobdiff_plain/0e293d049f3d4dac748a1630b8258ea10b709db2..0b364a7665d79821e7bc417a97b3cbb8ad10dcc3:/TODO?ds=sidebyside diff --git a/TODO b/TODO index 18d2325..3438f7e 100644 --- a/TODO +++ b/TODO @@ -1,23 +1,46 @@ Ideas / TODO: -* Hacer el protocolo completamente introspectivo, de manera que el cliente pueda - ser muy simple y genérico y en caso de agregar funcionalidad no sea necesario - modificarlo. - -* Evaluar hacer un RootHandler en vez de un diccionario con los handlers de la - raiz para simplificar la introspección y tener un help/commands global. - -* Evaluar que el dispatcher vea si se llama a un HandlerContainer y de ser así - que tire una ayuda en vez de un CommandNotFound (por ejemplo si se pone: - "dhcp" solo que tire una ayuda). Y si hay un subcomando no encontrado, que - tire un Command Not Found in handler (por ej "dhcp lala" -> Command "lala" not - found in "dhcp"). +* Revisar interacción entre firewall y nat que ambos usan iptables. Es probable + que al manipular reglas por número de índice se complique todo porque tengo + indices separados por tipo de regla, entonces si pongo borrar la 2 tal vez es + la 13 en vez de la dos porque hay otras 11 reglas de otros sub-servicios que + usan iptables. Tal vez la solución simple es hacer algo como: + router firewall add [regla] + router nat masq add [masq] + router nat forward add [port] + router nat snat add [snat] + (u organizándolo de otra forma pero que tengan todos un root en común) + +* Agregar soporte de opciones de línea de comando/archivo de conf para: + * Dry run. + * Seleccionar servicios a usar. + * Puerto/bind addr. + * Logging. + * Paths. + +* SubHandlers: + * ComposeDictSubHandler con soporte de dirty/del/add (para ip y DNS). + * Agregar SimpleDictSubHandler? (que no use una clase, que use un dict + de strings directamente, para Proxy Users por ej.). Ídem List. + * Agregar SetSubHandler? (para Proxy Hosts) * Agregar logging. * Agregar validación con formencode. +* Ver como manejar la información sobre si un servicio está andando o no. Si se + agrega una acción 'status' para ver el estado y si ese estado se saca de posta + de /proc o si es un estado interno y se asume que los servicios no se caen (no + creo que sea una buena idea esto último). Además habría que ver cuando arranca + el pymin, si se inician servicios automáticamente o no y si la info de qué + servicios iniciar o no es persistente y si puede configurarla el usuario. + +* No usar comandos con templates, porque después si no hay que ejecutarlos con + un shell (porque el template devuelve un string todo grande) y hay que andar + teniendo cuidado de escapar las cosas (y hay riesgos de seguridad de shell + injection). + Estas cosas quedan sujetas a necesitada y a definición del protocolo. Para mí lo ideal es que el protocolo de red sea igual que la consola del usuario, porque después de todo no va a ser más que eso, mandar comanditos.