Well... cheroke admin launcher is only for X window systems... will not work on servers etc.
Also about that permanent admin... please keep in mind that cherokee-admin ISN'T "multiuser/multisession" safe... beware that. For me that git based config file thingy is... nonsense, sorry for that David but putting "git"everywhere is a nonsense for me. Especially for that kind of things... what for would be useful ? How often would you need to "go back" 5 revisions(or more)? 25-01-2012 07:40 użytkownik "Voltron" <[email protected]> napisał: > 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 >
_______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
