Construir un nuevo appliance con TKLDev

El TKLDev docs son grandes, pero también son una gran lectura. El objetivo de esta página es crear una simple visión general de crear un nuevo appliance.

Esto supone que has leído a través de la TKLDev docs, tener una instancia de TKLDev corriendo y han confirmado que todo funciona como debe construcción de un núcleo ISO.

Prerrequisitos

Se requerirá el uso de la línea de mando, pero de particular relevancia son:

• apt; e.g. apt-get; apt-cache etc - esencial para la instalación de paquetes
• git; e.g. git clone; git commit; git push - esencial para trabajar con control de versiones git
• GitHub - Consiga una cuenta GitHub gratuita si no tienes uno.
  • Primer en git y GitHub

• Si eres nuevo en git/GitHub, establece tu TKLDev para GitHub:

• Configuración de git en el servidor TKLDev por establecer un nombre de usuario y email (Utilice el mismo correo electrónico que su cuenta GitHub).
• Luego tienes 2 opciones para la autenticación; las urls que utilizas para tu reposo GitHub dependerán de qué opción hagas:
  • SSH Mi preferencia y recomendación. generar un teclado SSH (ignorar otras secciones de esa página) " agregar su clave pública a GitHub); O
  • HTTPS - esto debería funcionar bien también, pero yo lo he usado, así que estás un poco solo.

¡Vamos!

Este proceso funciona para desarrollar un nuevo applianceAunque no es el único flujo de trabajo.

git clone https://github.com/turnkeylinux-apps/<base-appliance-name>.git
mv <base-appliance-name> <new-appliance-name>
cd <new-appliance-name>
rm -rf .git
git-init

1. Research su software e instalarlo en una instalación limpia el appliance que es el mejor punto de partida. Hacer que funcione como debe, mientras que documenta cuidadosamente cada paso. Lo hago en un VM y mi documentación es generalmente bajo comandos.
2. Decidir un nombre para su nuevo appliance. A menudo esto será evidente por sí mismo; otras veces no tanto...
3. En su TKLDev appliance, clone la base appliance (que decidió en el paso 1) y vuelva a llamar el directorio resultante (como por decisión en el paso 2) a su nuevo nombre appliance (no hay espacios). Entonces (re)inicializarlo como un git repo.
4. Crear un nuevo repo en GitHub llamado el mismo que su nuevo nombre appliance; es decir, el nombre del nuevo repo.
5. Sincronice su repo local y su GitHub (remote) uno (y comprometerse).
6. Tenga en cuenta que los paquetes que se instalan desde los repos predeterminados (es decir, TurnKey y Debian depósitos predeterminados) deben ser añadidos al plan; por ejemplo. Plan LAMP (y comprometerse)
7. Crear un script de instalación de la documentación hecha en el paso 1 y ponerlo en un script en el directorio conf.d; por ejemplo. LAMP conf principal.d (y comprometerse).
8. Y/o los archivos pueden ser añadidos al directorio overlay; por ejemplo. Superposición LAMP (y comprometerse).
9. Actualización del readme (por ejemplo. LAMP README.rst con información relevante para su nuevo appliance. Puede utilizar el existente como plantilla, pero probablemente querrá hacer una revisión importante.
10. Actualización de los cambios (por ejemplo. LAMP changelog. De nuevo usted puede querer utilizar algo de lo que está allí como una plantilla (aunque deshacerse de toda la información vieja ya que esta será la primera versión de un nuevo appliance). Si quieres seguir el progreso de tu trabajo No use el cambio, crear otro archivo para eso.
11. Puede utilizar la sección de problemas de su GitHub repo para errores y funciones planificadas si lo desea. Esto funciona mucho si varias personas están trabajando juntas.
12. Desarrolla tu ganchos init. Todos los factores únicos como contraseñas deben ser generados por el auto (por ejemplo, la aplicación MySQL contraseña de usuario) o interactivo (por ejemplo, una contraseña de usuario). Tenga en cuenta que el inithooks interactivo requiere la capacidad de ser preseedido.
13. Inicialmente hago root.patched 'entonces 'fab-chroot build/root.patched' para la prueba y el tweaking. Sigue trabajando en el appliance hasta que sea no utilizados y sin error. funciona como se espera en la caja de arena (comprometiéndose mientras haces cambios).
14. Construir finalmente ('make') y probar ISO (en un VM).
15. Celebrar! :)

     

Sugiero que se comprometan con frecuencia, entonces es fácil ver lo que se ha hecho y en qué orden, puedes limpiar la historia de la git más adelante si quieres. Normalmente solo empujo a GitHub cada vez (una vez una sesión). Aunque a veces usando el GitHub WebUI para ver su código puede ser una manera práctica de ver todo en un lugar.