You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 15, 2021. It is now read-only.
Currently we use db-common to handle databases. This doesn't port well to other distros, and isn't that pleasant to use. We also use the CRON functions to do minor upgrades and other things like that.
Proposal:
Use a "sql" manager to have pure sql patches for all database changes. Split this into it's own package that all other packages can depend on. This package will handle the radius and radmin databases, for all schema related things, and any pure sql related updates.
(Split out of freeradius the database settings into another file as well, so updates to sql.conf.grase can take place)
This package also needs to handle generating a random password for radius and radmin databases, and ensuring that they can actually login. Maybe we can try using the built in Debian "maintenance" mysql password to do our "root" work, and fallback to prompting the user? (Prompting requires debconf).
CRON functions will only do non schema related changes, and can ensure that the database schema version is greater than the required one, as well as having an internal "patch" applied kind of table for ensuring both sql and cron "patches" are marked off as done when applied.
{
"status": "new",
"changetime": "2012-03-09T03:52:22",
"description": "Currently we use db-common to handle databases. This doesn't port well to other distros, and isn't that pleasant to use. We also use the CRON functions to do minor upgrades and other things like that.\n\nProposal:\nUse a \"sql\" manager to have pure sql patches for all database changes. Split this into it's own package that all other packages can depend on. This package will handle the radius and radmin databases, for all schema related things, and any pure sql related updates.\n(Split out of freeradius the database settings into another file as well, so updates to sql.conf.grase can take place)\nThis package also needs to handle generating a random password for radius and radmin databases, and ensuring that they can actually login. Maybe we can try using the built in Debian \"maintenance\" mysql password to do our \"root\" work, and fallback to prompting the user? (Prompting requires debconf).\nCRON functions will only do non schema related changes, and can ensure that the database schema version is greater than the required one, as well as having an internal \"patch\" applied kind of table for ensuring both sql and cron \"patches\" are marked off as done when applied.",
"reporter": "tim",
"cc": "",
"resolution": "",
"_ts": "1331265142587051",
"component": "Other Backend",
"summary": "Need new system to handle database and upgrades",
"priority": "major",
"keywords": "packaging, database",
"version": "3.6",
"time": "2012-03-09T03:52:22",
"milestone": "4.0",
"owner": "tim",
"type": "enhancement"
}
The text was updated successfully, but these errors were encountered:
Currently we use db-common to handle databases. This doesn't port well to other distros, and isn't that pleasant to use. We also use the CRON functions to do minor upgrades and other things like that.
Proposal:
Use a "sql" manager to have pure sql patches for all database changes. Split this into it's own package that all other packages can depend on. This package will handle the radius and radmin databases, for all schema related things, and any pure sql related updates.
(Split out of freeradius the database settings into another file as well, so updates to sql.conf.grase can take place)
This package also needs to handle generating a random password for radius and radmin databases, and ensuring that they can actually login. Maybe we can try using the built in Debian "maintenance" mysql password to do our "root" work, and fallback to prompting the user? (Prompting requires debconf).
CRON functions will only do non schema related changes, and can ensure that the database schema version is greater than the required one, as well as having an internal "patch" applied kind of table for ensuring both sql and cron "patches" are marked off as done when applied.
Migrated from http://trac.grasehotspot.org/ticket/65
The text was updated successfully, but these errors were encountered: