Mailing List Archive

I support the ideas of both the cancel/undo.

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..

Tad odd that we have such a paranoid admin but you can do the polar
opposite and run cherokee-admin passwordless. The middle ground is
letting the admin set the password. Please :)

On 1/23/12, Brade <bradezone@gmail.com> wrote:
> This has been happening way too often: After setting up a virtual host, when
> I drag it to a new location on the list of virtual hosts, it frequently
> causes another host to disappear from the list. It seems to be random for
> how often this happens and which virtual host disappears, but there's no way
> to recover the original settings other than stopping cherokee-admin and
> relaunching it. Does this happen to anyone else, or is there a fix?
>
> This is another good argument for why Cherokee needs a "cancel" button
> instead of only a "save" button. When you want things to go back to the last
> successful save. Another nicety would be for a persistent password for
> cherokee-admin, since I like to save my passwords and I'm forced to change
> it each time cherokee-admin reloads. But anyhoo, other than this (fairly
> annoying) problem, Cherokee's been great.
>
> --
> View this message in context:
> http://cherokee-web-server-general.1049476.n5.nabble.com/Drag-and-drop-virtual-servers-makes-host-disappear-tp5181274p5181274.html
> Sent from the Cherokee Web Server - General mailing list archive at
> Nabble.com.
> _______________________________________________
> Cherokee mailing list
> Cherokee@lists.octality.com
> http://lists.octality.com/listinfo/cherokee
>
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

On Mon, Jan 23, 2012 at 3:04 PM, pub crawler <pubcrawler.com@gmail.com>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: m.david@3rdandUrban.com
Voice: (801) 742-1064
http://amp.fm | http://mdavidpeterson.com

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 <m.david@3rdandurban.com> wrote:
> On Mon, Jan 23, 2012 at 3:04 PM, pub crawler
> <pubcrawler.com@gmail.com>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: m.david@3rdandUrban.com
> Voice: (801) 742-1064
> http://amp.fm | http://mdavidpeterson.com
>
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

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 <pubcrawler.com@gmail.com> 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 <m.david@3rdandurban.com> wrote:
>> On Mon, Jan 23, 2012 at 3:04 PM, pub crawler
>> <pubcrawler.com@gmail.com>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: m.david@3rdandUrban.com
>> Voice: (801) 742-1064
>> http://amp.fm | http://mdavidpeterson.com
>>
>
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

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 <pubcrawler....@gmail.com> 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 <pubcrawler....@gmail.com> 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 <m.da...@3rdandurban.com> wrote:
> >> On Mon, Jan 23, 2012 at 3:04 PM, pub crawler
> >> <pubcrawler....@gmail.com>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: m.da...@3rdandUrban.com
> >> Voice: (801) 742-1064
> >>http://amp.fm|http://mdavidpeterson.com
>
> _______________________________________________
> Cherokee mailing list
> Chero...@lists.octality.comhttp://lists.octality.com/listinfo/cherokee
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

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" <nhytro@googlemail.com> 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 <pubcrawler....@gmail.com> 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 <pubcrawler....@gmail.com> 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 <m.da...@3rdandurban.com> wrote:
> > >> On Mon, Jan 23, 2012 at 3:04 PM, pub crawler
> > >> <pubcrawler....@gmail.com>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: m.da...@3rdandUrban.com
> > >> Voice: (801) 742-1064
> > >>http://amp.fm|http://mdavidpeterson.com
> >
> > _______________________________________________
> > Cherokee mailing list
> > Chero...@lists.octality.comhttp://lists.octality.com/listinfo/cherokee
> _______________________________________________
> Cherokee mailing list
> Cherokee@lists.octality.com
> http://lists.octality.com/listinfo/cherokee
>

Another option is to tell cherokee-admin to only listen to localhost
(passwordless) and then connect via SSH forwarding. However, if you take
this approach, you'd have to trust every user that has SSH access to the
server (which may or may not be doable in your situation).

I'd love the ability to use client-side SSL certificates (not sure what PGP
certificates are or how they differ).


On Tue, Jan 24, 2012 at 4:52 PM, pub crawler <pubcrawler.com@gmail.com>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 <m.david@3rdandurban.com> wrote:
> > On Mon, Jan 23, 2012 at 3:04 PM, pub crawler
> > <pubcrawler.com@gmail.com>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: m.david@3rdandUrban.com
> > Voice: (801) 742-1064
> > http://amp.fm | http://mdavidpeterson.com
> >
> _______________________________________________
> Cherokee mailing list
> Cherokee@lists.octality.com
> http://lists.octality.com/listinfo/cherokee
>

On Tue, Jan 24, 2012 at 6:40 AM, M. David Peterson
<m.david@3rdandurban.com>wrote:

> On Mon, Jan 23, 2012 at 3:04 PM, pub crawler <pubcrawler.com@gmail.com>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?
>

It's an interesting idea. It'd vote +1 as long as we managed to implement
it as a weak dependency (this is, it'd also work if you did not have git
installed).

--
Greetings, alo
http://www.octality.com/

On Wed, Feb 1, 2012 at 9:46 AM, Alvaro Lopez Ortega <alvaro@octality.com> wrote:
>
> It's an interesting idea. It'd vote +1 as long as we managed to implement it
> as a weak dependency (this is, it'd also work if you did not have git
> installed).

Then I need to change my opinion about that idea. But dependency less
system like that is a good idea I think. Maybe the best will be to
have something like abstract layer on top of it - then when no git /
hg use kind off 'fallback mode' ?


Greetings,
Jedrzej Nowak
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

On 02/01/2012 10:32 AM, Jędrzej Nowak wrote:
> On Wed, Feb 1, 2012 at 9:46 AM, Alvaro Lopez Ortega<alvaro@octality.com> wrote:
>> >
>> > It's an interesting idea. It'd vote +1 as long as we managed to implement it
>> > as a weak dependency (this is, it'd also work if you did not have git
>> > installed).
> Then I need to change my opinion about that idea. But dependency less
> system like that is a good idea I think. Maybe the best will be to
> have something like abstract layer on top of it - then when no git /
> hg use kind off 'fallback mode' ?

It's completely up to us how complex we want it to be. The question,
though, is whether it'd worth supporting more than a single version
control system.
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

I think it's important to have "fallback" mode, when there is no gih/hg or
whatever.

I now wonder if it's right way to go... to have the cherokee.conf versioned
"outside" admin is also easy, so I'm not sure about that integration again.

01-02-2012 18:58 użytkownik "Alvaro Lopez Ortega" <alvaro@alobbs.com>
napisał:
>
> On 02/01/2012 10:32 AM, Jędrzej Nowak wrote:
>>
>> On Wed, Feb 1, 2012 at 9:46 AM, Alvaro Lopez Ortega<alvaro@octality.com>
wrote:
>>>
>>> >
>>> > It's an interesting idea. It'd vote +1 as long as we managed to
implement it
>>> > as a weak dependency (this is, it'd also work if you did not have git
>>> > installed).
>>
>> Then I need to change my opinion about that idea. But dependency less
>> system like that is a good idea I think. Maybe the best will be to
>> have something like abstract layer on top of it - then when no git /
>> hg use kind off 'fallback mode' ?
>
>
> It's completely up to us how complex we want it to be. The question,
though, is whether it'd worth supporting more than a single version control
system.

On Wed, Feb 1, 2012 at 7:46 PM, Alvaro Lopez Ortega <alvaro@octality.com>wrote:

>
>>> 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?
>>
>
> It's an interesting idea. It'd vote +1 as long as we managed to implement
> it as a weak dependency (this is, it'd also work if you did not have git
> installed).
>

You could have some sort of plugin system for Cherokee-Admin, along with a
"hook"/callback system that lets plugins hook in to certain events. Then
you 'd just need to add a "Configuration saved" hook that a Git / Mercurial
plugin could listen to. This would keep the config source control stuff
outside of the core.