I think this problem would be solved if the admin laucher was packaged in the distributions
http://groups.google.com/group/cherokee-http/browse_thread/thread/68e9cd5385257c46?hl=en# On Jan 24, 7:30 am, pub crawler <[email protected]> wrote: > I have cherokee-admin running now with permanent password I've selected. :) > > This is a hack, but it works. (well some issues with Cherokee that > need cleaned up --- will send in bug reports for them). > > I set up a new A record in DNS: > > admin.domain.ext > > Created a new Virtual Server in Cherokee to handle admin.domain.ext > > Delete all rules from the new Default stuff for virtual server. > > All that should be left is one rule: Default > > Add Host Match: *admin.domain.ext > > Under Behavior: > Handler: HTTP Reverse Proxy > Select Balancer (need to add a new Source) > New Source: 127.0.0.1:9090 > > Go to Security tab: > Validation Mechanism: Fixed List > Methods: Basic > Realm: secret > > Add a new user and password pair. > > Kill cherokee-admin > > Start cherokee-admin as follows: > cherokee-admin -u -b 127.0.0.1 & > > In browser this is your URL: > > http://admin.domain.ext > > (example:http://admin.yourdomain.com) > > You should be prompted to provide your username and password (this is > the pair you provided above). > > If this works, you effectively have Cherokee-admin running > 'passwordless' with a set password of your choosing. > > So far, have caught several 500 errors in the admin and the RRDTOOL > traffic graphs are broken / won't display. It's totally functional > for typical admin work, just did some in there :) If you stop > cherokee, the admin will stop also in this hacked mode. Buyer > beware... > > On 1/24/12, pub crawler <[email protected]> wrote: > > > > > > > > > Umm, well, again, Cherokee-admin can be ran with the default generated > > password behavior or one can use the -u to make it passwordless. There > > isn't any safeguard to ask the user if they are sure of what they are > > doing with a -u ran admin. :) That's the big potential opening > > especially where people become more frustrated with Cherokee's good > > intentioned, but hard on the admin random password. > > > Affording manual password setting isn't unusual, it's how everything > > else works :) > > > I am all for a PGP or other crypto key based mechanism though. +1 > > Unsure of the complexity for users and to implement. Doubt it's a > > lunch hour project. > > > I have a dozen machines running Cherokee actively. So the admin > > stop/start/password copy and paste dance has me worn out :) I am > > about to run the admin passwordless and put other protections in place > > --- like a user and password security pop up standard validation with > > whatever I have hard set. Yeah, reverse proxy will suffice :) > > > Actually off now to test this way of hard setting password and leaving > > the admin running permanent passwordless. > > > On 1/24/12, M. David Peterson <[email protected]> wrote: > >> On Mon, Jan 23, 2012 at 3:04 PM, pub crawler > >> <[email protected]>wrote: > > >>> I support the ideas of both the cancel/undo. > > >> Better still would be using a git-based versioning system that generates > >> a > >> commit with every save, exposing the ability to revert back to a previous > >> revision via a simple drop-down listing the sha1 of each of the previous > >> commits. There are a ton of additional advantages to moving towards a > >> git-based system (ease of deployment of configuration files to other > >> nodes > >> via git push, etc.) but this particular capability would be reason > >> enough. > > >> Alvaro, your thoughts? > > >>> I also support the ability to set password for the cherokee-admin. > >>> Constant annoyance for me to kill cherokee-admin and restart it just > >>> to get a password to log-in.. > > >> -1: Too many people will keep cherokee-admin up and running over a > >> non-secure HTTP connection listening on 0.0.0.0. The last thing we need > >> to have happen is for someones Cherokee instance to be compromised and > >> for > >> some script kiddie to be given full control over its configuration. > > >> I do agree that making the login process less of a burden is a beneficial > >> feature. Providing support for client-side PGP digital certificates* > >> that > >> have been registered with a given Cherokee instance would be a MUCH more > >> secure and in many ways easier to manage solution. > > >> I'm not sure what would be required to implement support for client side > >> PGP certs, but at the moment the randomly generated password solution > >> works > >> well enough to consider this a lower priority feature, I would think, if > >> it > >> requires anything more than what can be added with minimal effort (read: > >> over a typical lunch break) using existing OSS libraries. > > >> *http://www.pgptrustcenter.com/digital-certificate-solutions > > >> -- > >> /M:D > > >> M. David Peterson > >> Co-Founder & Chief Architect, 3rd&Urban, LLC > >> Email: [email protected] > >> Voice: (801) 742-1064 > >>http://amp.fm|http://mdavidpeterson.com > > _______________________________________________ > Cherokee mailing list > [email protected]http://lists.octality.com/listinfo/cherokee _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
