| 2018-04-18 09:50:16 |
Dimitri John Ledkov |
bug |
|
|
added bug |
| 2018-04-18 09:50:26 |
Dimitri John Ledkov |
bug task added |
|
livecd-rootfs (Ubuntu) |
|
| 2018-04-18 10:03:49 |
Dimitri John Ledkov |
description |
Subiquity is adding offline installation of capability, using livecd-rootfs squashfs that are generated in launchpad and shipped on the ISO.
These squashfsi have maas-rack-controller or maas meta-packages pre-installed.
Upon install, the contents of these are copied to target disk, and customized.
However, currently, this yields to the awkward situation that all MAASes installed this way, have identical secret / db password / uuid, which is not nice.
One option is for me to undo, all the things that maas-*-controller.postinst did at the end of squashfs generation. And then in post-install execute dpkg-reconfigure to complete initialisation of all the uuids / random passwords / etc.
I fear that "undoing" all the config changes myself, in livecd-rootfs, might be fragile, and may lag any changes that are done to in .postinst. Thus I wonder, if maas would be open to support a "dpkg-reconfigure later" mode.
Something like being sensitive to a stamp file [ ! -f /run/maas-no-configure ] and if that is true, not initialize dbconfig database, not generate db passwords, and so on.
Is this something maas packaging is willing to support? and I can work on providing such a matching change to the postinst & livecd-rootfs. |
Subiquity is adding offline installation of capability, using livecd-rootfs squashfs that are generated in launchpad and shipped on the ISO.
These squashfsi have maas-rack-controller or maas meta-packages pre-installed.
Upon install, the contents of these are copied to target disk, and customized.
However, currently, this yields to the awkward situation that all MAASes installed this way, have identical secret / db password / uuid, which is not nice.
One option is for me to undo, all the things that maas-*-controller.postinst did at the end of squashfs generation. And then in post-install execute dpkg-reconfigure to complete initialisation of all the uuids / random passwords / etc.
I fear that "undoing" all the config changes myself, in livecd-rootfs, might be fragile, and may lag any changes that are done to in .postinst. Thus I wonder, if maas would be open to support a "dpkg-reconfigure later" mode.
Something like being sensitive to a stamp file [ ! -f /run/maas-no-configure ] and if that is true, not initialize dbconfig database, not generate db passwords, and so on.
Is this something maas packaging is willing to support? and I can work on providing such a matching change to the postinst & livecd-rootfs.
maas-rack-controller.postinst assesment:
* configure_logging is harmless
* configure_libdir is harmless
* configure_maas_url is harmless
- debconf maas-url is not set
- should be done at subiquity config time
* maas-rack upgrade-cluster
- TODO not sure what that does on first install
* configure_cluster_uuid
- should be short-circuited
- should be done at subiquity config time
* configure_cluster_authbind seems harmless
* upgrade_from_cluster_controller is harmless
* configure_shared_secret is harmless
- debconf shard-secret is not set
- should be done at subiquity config time |
|
| 2018-04-18 10:05:53 |
Dimitri John Ledkov |
description |
Subiquity is adding offline installation of capability, using livecd-rootfs squashfs that are generated in launchpad and shipped on the ISO.
These squashfsi have maas-rack-controller or maas meta-packages pre-installed.
Upon install, the contents of these are copied to target disk, and customized.
However, currently, this yields to the awkward situation that all MAASes installed this way, have identical secret / db password / uuid, which is not nice.
One option is for me to undo, all the things that maas-*-controller.postinst did at the end of squashfs generation. And then in post-install execute dpkg-reconfigure to complete initialisation of all the uuids / random passwords / etc.
I fear that "undoing" all the config changes myself, in livecd-rootfs, might be fragile, and may lag any changes that are done to in .postinst. Thus I wonder, if maas would be open to support a "dpkg-reconfigure later" mode.
Something like being sensitive to a stamp file [ ! -f /run/maas-no-configure ] and if that is true, not initialize dbconfig database, not generate db passwords, and so on.
Is this something maas packaging is willing to support? and I can work on providing such a matching change to the postinst & livecd-rootfs.
maas-rack-controller.postinst assesment:
* configure_logging is harmless
* configure_libdir is harmless
* configure_maas_url is harmless
- debconf maas-url is not set
- should be done at subiquity config time
* maas-rack upgrade-cluster
- TODO not sure what that does on first install
* configure_cluster_uuid
- should be short-circuited
- should be done at subiquity config time
* configure_cluster_authbind seems harmless
* upgrade_from_cluster_controller is harmless
* configure_shared_secret is harmless
- debconf shard-secret is not set
- should be done at subiquity config time |
Subiquity is adding offline installation of capability, using livecd-rootfs squashfs that are generated in launchpad and shipped on the ISO.
These squashfsi have maas-rack-controller or maas meta-packages pre-installed.
Upon install, the contents of these are copied to target disk, and customized.
However, currently, this yields to the awkward situation that all MAASes installed this way, have identical secret / db password / uuid, which is not nice.
One option is for me to undo, all the things that maas-*-controller.postinst did at the end of squashfs generation. And then in post-install execute dpkg-reconfigure to complete initialisation of all the uuids / random passwords / etc.
I fear that "undoing" all the config changes myself, in livecd-rootfs, might be fragile, and may lag any changes that are done to in .postinst. Thus I wonder, if maas would be open to support a "dpkg-reconfigure later" mode.
Something like being sensitive to a stamp file [ ! -f /run/maas-no-configure ] and if that is true, not initialize dbconfig database, not generate db passwords, and so on.
Is this something maas packaging is willing to support? and I can work on providing such a matching change to the postinst & livecd-rootfs.
maas-rack-controller.postinst assesment:
* configure_logging is harmless
* configure_libdir is harmless
* configure_maas_url is harmless
- debconf maas-url is not set
- should be done at subiquity config time
* maas-rack upgrade-cluster
- TODO not sure what that does on first install
- It looks like "ugprade hooks"
- I hope these are not doing anything on first-install (as in, these do not double up as initialisation, and are not UUID specific)
* configure_cluster_uuid
- should be short-circuited
- should be done at subiquity config time
* configure_cluster_authbind seems harmless
* upgrade_from_cluster_controller is harmless
* configure_shared_secret is harmless
- debconf shard-secret is not set
- should be done at subiquity config time |
|
| 2018-04-18 10:09:17 |
Dimitri John Ledkov |
description |
Subiquity is adding offline installation of capability, using livecd-rootfs squashfs that are generated in launchpad and shipped on the ISO.
These squashfsi have maas-rack-controller or maas meta-packages pre-installed.
Upon install, the contents of these are copied to target disk, and customized.
However, currently, this yields to the awkward situation that all MAASes installed this way, have identical secret / db password / uuid, which is not nice.
One option is for me to undo, all the things that maas-*-controller.postinst did at the end of squashfs generation. And then in post-install execute dpkg-reconfigure to complete initialisation of all the uuids / random passwords / etc.
I fear that "undoing" all the config changes myself, in livecd-rootfs, might be fragile, and may lag any changes that are done to in .postinst. Thus I wonder, if maas would be open to support a "dpkg-reconfigure later" mode.
Something like being sensitive to a stamp file [ ! -f /run/maas-no-configure ] and if that is true, not initialize dbconfig database, not generate db passwords, and so on.
Is this something maas packaging is willing to support? and I can work on providing such a matching change to the postinst & livecd-rootfs.
maas-rack-controller.postinst assesment:
* configure_logging is harmless
* configure_libdir is harmless
* configure_maas_url is harmless
- debconf maas-url is not set
- should be done at subiquity config time
* maas-rack upgrade-cluster
- TODO not sure what that does on first install
- It looks like "ugprade hooks"
- I hope these are not doing anything on first-install (as in, these do not double up as initialisation, and are not UUID specific)
* configure_cluster_uuid
- should be short-circuited
- should be done at subiquity config time
* configure_cluster_authbind seems harmless
* upgrade_from_cluster_controller is harmless
* configure_shared_secret is harmless
- debconf shard-secret is not set
- should be done at subiquity config time |
Subiquity is adding offline installation of capability, using livecd-rootfs squashfs that are generated in launchpad and shipped on the ISO.
These squashfsi have maas-rack-controller or maas meta-packages pre-installed.
Upon install, the contents of these are copied to target disk, and customized.
However, currently, this yields to the awkward situation that all MAASes installed this way, have identical secret / db password / uuid, which is not nice.
One option is for me to undo, all the things that maas-*-controller.postinst did at the end of squashfs generation. And then in post-install execute dpkg-reconfigure to complete initialisation of all the uuids / random passwords / etc.
I fear that "undoing" all the config changes myself, in livecd-rootfs, might be fragile, and may lag any changes that are done to in .postinst. Thus I wonder, if maas would be open to support a "dpkg-reconfigure later" mode.
Something like being sensitive to a stamp file [ ! -f /run/maas-no-configure ] and if that is true, not initialize dbconfig database, not generate db passwords, and so on.
Is this something maas packaging is willing to support? and I can work on providing such a matching change to the postinst & livecd-rootfs.
maas-rack-controller.postinst assesment:
* configure_logging is harmless
* configure_libdir is harmless
* configure_maas_url is harmless
- debconf maas-url is not set
- should be done at subiquity config time
* maas-rack upgrade-cluster
- TODO not sure what that does on first install
- It looks like "ugprade hooks"
- I hope these are not doing anything on first-install (as in, these do not double up as initialisation, and are not UUID specific)
* configure_cluster_uuid
- should be short-circuited
- should be done at subiquity config time
* configure_cluster_authbind seems harmless
* upgrade_from_cluster_controller is harmless
* configure_shared_secret is harmless
- debconf shard-secret is not set
- should be done at subiquity config time
livecd-rootfs minimal action - drop /etc/maas/rackd.conf |
|
| 2018-04-18 10:28:22 |
Dimitri John Ledkov |
description |
Subiquity is adding offline installation of capability, using livecd-rootfs squashfs that are generated in launchpad and shipped on the ISO.
These squashfsi have maas-rack-controller or maas meta-packages pre-installed.
Upon install, the contents of these are copied to target disk, and customized.
However, currently, this yields to the awkward situation that all MAASes installed this way, have identical secret / db password / uuid, which is not nice.
One option is for me to undo, all the things that maas-*-controller.postinst did at the end of squashfs generation. And then in post-install execute dpkg-reconfigure to complete initialisation of all the uuids / random passwords / etc.
I fear that "undoing" all the config changes myself, in livecd-rootfs, might be fragile, and may lag any changes that are done to in .postinst. Thus I wonder, if maas would be open to support a "dpkg-reconfigure later" mode.
Something like being sensitive to a stamp file [ ! -f /run/maas-no-configure ] and if that is true, not initialize dbconfig database, not generate db passwords, and so on.
Is this something maas packaging is willing to support? and I can work on providing such a matching change to the postinst & livecd-rootfs.
maas-rack-controller.postinst assesment:
* configure_logging is harmless
* configure_libdir is harmless
* configure_maas_url is harmless
- debconf maas-url is not set
- should be done at subiquity config time
* maas-rack upgrade-cluster
- TODO not sure what that does on first install
- It looks like "ugprade hooks"
- I hope these are not doing anything on first-install (as in, these do not double up as initialisation, and are not UUID specific)
* configure_cluster_uuid
- should be short-circuited
- should be done at subiquity config time
* configure_cluster_authbind seems harmless
* upgrade_from_cluster_controller is harmless
* configure_shared_secret is harmless
- debconf shard-secret is not set
- should be done at subiquity config time
livecd-rootfs minimal action - drop /etc/maas/rackd.conf |
Subiquity is adding offline installation of capability, using livecd-rootfs squashfs that are generated in launchpad and shipped on the ISO.
These squashfsi have maas-rack-controller or maas meta-packages pre-installed.
Upon install, the contents of these are copied to target disk, and customized.
However, currently, this yields to the awkward situation that all MAASes installed this way, have identical secret / db password / uuid, which is not nice.
One option is for me to undo, all the things that maas-*-controller.postinst did at the end of squashfs generation. And then in post-install execute dpkg-reconfigure to complete initialisation of all the uuids / random passwords / etc.
I fear that "undoing" all the config changes myself, in livecd-rootfs, might be fragile, and may lag any changes that are done to in .postinst. Thus I wonder, if maas would be open to support a "dpkg-reconfigure later" mode.
Something like being sensitive to a stamp file [ ! -f /run/maas-no-configure ] and if that is true, not initialize dbconfig database, not generate db passwords, and so on.
Is this something maas packaging is willing to support? and I can work on providing such a matching change to the postinst & livecd-rootfs.
maas-rack-controller.postinst assesment:
* configure_logging is harmless
* configure_libdir is harmless
* configure_maas_url is harmless
- debconf maas-url is not set
- should be done at subiquity config time
* maas-rack upgrade-cluster
- TODO not sure what that does on first install
- It looks like "ugprade hooks"
- I hope these are not doing anything on first-install (as in, these do not double up as initialisation, and are not UUID specific)
* configure_cluster_uuid
- should be short-circuited
- should be done at subiquity config time
* configure_cluster_authbind seems harmless
* upgrade_from_cluster_controller is harmless
* configure_shared_secret is harmless
- debconf shard-secret is not set
- should be done at subiquity config time
livecd-rootfs minimal action - drop /etc/maas/rackd.conf
maas-region-controller.postinst assesment:
* configure_mass_default_url maas/default-maas-url
- may potentially be troublesome, as may encode networking details of the livecd-rootfs machine
- should be short-circuited
- should be done at subiquity config time
* dbc_go maas-region-controller
... and sync_migrate_db / configure_migrate_maas_dns
... and local_config_set
- should be short-circuited
- should be done at subiquity config time
* maas/username
- mostly harmless
- should be short-circuited
- should be done at subiquity config time
livecd-rootfs minimal action
- undo dbconfig-common, eg. purge for maas-region-controller?
- drop database
- drop database user
- maas-region local_config_reset
- drop secret, if any
- drop uuid, if any
- drop /etc/maas/regiond.conf |
|
| 2018-04-19 12:30:15 |
Launchpad Janitor |
branch linked |
|
lp:~xnox/livecd-rootfs/clean-maas |
|
| 2018-04-19 20:23:44 |
Launchpad Janitor |
branch linked |
|
lp:livecd-rootfs |
|
| 2018-04-20 01:40:47 |
Launchpad Janitor |
livecd-rootfs (Ubuntu): status |
New |
Fix Released |
|
| 2018-04-23 21:39:33 |
Michael Hudson-Doyle |
bug |
|
|
added subscriber Michael Hudson-Doyle |
| 2020-11-10 14:19:13 |
Dimitri John Ledkov |
maas (Ubuntu): status |
New |
Won't Fix |
|
