Mailing List Archive

Am 22.01.2012 13:49, schrieb pub crawler:

> cherokee-admin starts, asks for login credentials but fails to load.
>
> This is version 1.2.101, but have same experience with 1.08.xx that
> ships with Debian currently.
>

I have the same problem on my local machine, running Fedora 16. Cherokee
version is 1.2.101.

Starting cherokee-admin with debugging and killing it after it timed out
returns the following:

DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2079 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2082 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2109 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..

Traceback (most recent call last):
File "/usr/share/cherokee/admin/server.py", line 197, in <module>
CTK.step()
File "/usr/share/cherokee/admin/CTK/CTK/Server.py", line 352, in step
srv._scgi.handle_request()
File "/usr/lib64/python2.7/SocketServer.py", line 265, in handle_request
Cherokee-admin is exiting..

There is a blog article about this with a workaround for Fedora 16, but
it does NOT work for me:
http://michael.grunewalder.com/2011/11/25/fixing-cherokee-admin-on-fedora-16-possibly-other-distros-too/

Thanks for any hints!
Gregor

_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

BTW: failed to point out this VPS is running Debian 6.xx...

Interesting link Gregor... I might give that a try just to see if it
actually works.

On 1/22/12, Gregor <public@openinformation.org> wrote:
> Am 22.01.2012 13:49, schrieb pub crawler:
>
>> cherokee-admin starts, asks for login credentials but fails to load.
>>
>> This is version 1.2.101, but have same experience with 1.08.xx that
>> ships with Debian currently.
>>
>
> I have the same problem on my local machine, running Fedora 16. Cherokee
> version is 1.2.101.
>
> Starting cherokee-admin with debugging and killing it after it timed out
> returns the following:
>
> DEBUG: SIGUSR1 invokes the console..
> SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2079 Port=4000
> DEBUG: SIGUSR1 invokes the console..
> SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2082 Port=4000
> DEBUG: SIGUSR1 invokes the console..
> SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2109 Port=4000
> DEBUG: SIGUSR1 invokes the console..
> SIGUSR2 prints a backtrace..
>
> Traceback (most recent call last):
> File "/usr/share/cherokee/admin/server.py", line 197, in <module>
> CTK.step()
> File "/usr/share/cherokee/admin/CTK/CTK/Server.py", line 352, in step
> srv._scgi.handle_request()
> File "/usr/lib64/python2.7/SocketServer.py", line 265, in handle_request
> Cherokee-admin is exiting..
>
> There is a blog article about this with a workaround for Fedora 16, but
> it does NOT work for me:
> http://michael.grunewalder.com/2011/11/25/fixing-cherokee-admin-on-fedora-16-possibly-other-distros-too/
>
> Thanks for any hints!
> Gregor
>
> _______________________________________________
> 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

I made the change as recommended in link above to hack the admin.

It failed to work...

I get this new error and the admin itself is quick to reply with a 503 error:

Traceback (most recent call last):
File "/usr/share/cherokee/admin/server.py", line 37, in <module>
import CTK
ImportError: No module named CTK
Traceback (most recent call last):
File "/usr/share/cherokee/admin/server.py", line 37, in <module>
import CTK
ImportError: No module named CTK
Traceback (most recent call last):
File "/usr/share/cherokee/admin/server.py", line 37, in <module>
import CTK
ImportError: No module named CTK
Traceback (most recent call last):
File "/usr/share/cherokee/admin/server.py", line 37, in <module>
import CTK
ImportError: No module named CTK
Traceback (most recent call last):
File "/usr/share/cherokee/admin/server.py", line 37, in <module>
import CTK
ImportError: No module named CTK

Now, the source I used for this from GIT, using the download of a zip
file. Did this today, so current.

Under /admin directory in this zipfile I do see a CTK subdirectory,
but it is empty... Perhaps the problem?

Can anyone shed light on how to resolve this error?

On 1/22/12, pub crawler <pubcrawler.com@gmail.com> wrote:
> BTW: failed to point out this VPS is running Debian 6.xx...
>
> Interesting link Gregor... I might give that a try just to see if it
> actually works.
>
> On 1/22/12, Gregor <public@openinformation.org> wrote:
>> Am 22.01.2012 13:49, schrieb pub crawler:
>>
>>> cherokee-admin starts, asks for login credentials but fails to load.
>>>
>>> This is version 1.2.101, but have same experience with 1.08.xx that
>>> ships with Debian currently.
>>>
>>
>> I have the same problem on my local machine, running Fedora 16. Cherokee
>> version is 1.2.101.
>>
>> Starting cherokee-admin with debugging and killing it after it timed out
>> returns the following:
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2079 Port=4000
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2082 Port=4000
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2109 Port=4000
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>>
>> Traceback (most recent call last):
>> File "/usr/share/cherokee/admin/server.py", line 197, in <module>
>> CTK.step()
>> File "/usr/share/cherokee/admin/CTK/CTK/Server.py", line 352, in step
>> srv._scgi.handle_request()
>> File "/usr/lib64/python2.7/SocketServer.py", line 265, in
>> handle_request
>> Cherokee-admin is exiting..
>>
>> There is a blog article about this with a workaround for Fedora 16, but
>> it does NOT work for me:
>> http://michael.grunewalder.com/2011/11/25/fixing-cherokee-admin-on-fedora-16-possibly-other-distros-too/
>>
>> Thanks for any hints!
>> Gregor
>>
>> _______________________________________________
>> 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

Rabbit hole goes deeper on this one.

Copied /admin/CTK directory from 1.21.xx release and placed it in
/usr/share/cherokee/admin

Now we get a different error:

ImportError: No module named configured
Traceback (most recent call last):
File "/usr/share/cherokee/admin/server.py", line 38, in <module>
import OWS_Login
File "/usr/share/cherokee/admin/OWS_Login.py", line 26, in <module>
import XMLServerDigest
File "/usr/share/cherokee/admin/XMLServerDigest.py", line 32, in <module>
import configured

These three python files are all present where they should be...

On 1/22/12, pub crawler <pubcrawler.com@gmail.com> wrote:
> I made the change as recommended in link above to hack the admin.
>
> It failed to work...
>
> I get this new error and the admin itself is quick to reply with a 503
> error:
>
> Traceback (most recent call last):
> File "/usr/share/cherokee/admin/server.py", line 37, in <module>
> import CTK
> ImportError: No module named CTK
> Traceback (most recent call last):
> File "/usr/share/cherokee/admin/server.py", line 37, in <module>
> import CTK
> ImportError: No module named CTK
> Traceback (most recent call last):
> File "/usr/share/cherokee/admin/server.py", line 37, in <module>
> import CTK
> ImportError: No module named CTK
> Traceback (most recent call last):
> File "/usr/share/cherokee/admin/server.py", line 37, in <module>
> import CTK
> ImportError: No module named CTK
> Traceback (most recent call last):
> File "/usr/share/cherokee/admin/server.py", line 37, in <module>
> import CTK
> ImportError: No module named CTK
>
> Now, the source I used for this from GIT, using the download of a zip
> file. Did this today, so current.
>
> Under /admin directory in this zipfile I do see a CTK subdirectory,
> but it is empty... Perhaps the problem?
>
> Can anyone shed light on how to resolve this error?
>
> On 1/22/12, pub crawler <pubcrawler.com@gmail.com> wrote:
>> BTW: failed to point out this VPS is running Debian 6.xx...
>>
>> Interesting link Gregor... I might give that a try just to see if it
>> actually works.
>>
>> On 1/22/12, Gregor <public@openinformation.org> wrote:
>>> Am 22.01.2012 13:49, schrieb pub crawler:
>>>
>>>> cherokee-admin starts, asks for login credentials but fails to load.
>>>>
>>>> This is version 1.2.101, but have same experience with 1.08.xx that
>>>> ships with Debian currently.
>>>>
>>>
>>> I have the same problem on my local machine, running Fedora 16. Cherokee
>>> version is 1.2.101.
>>>
>>> Starting cherokee-admin with debugging and killing it after it timed out
>>> returns the following:
>>>
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2079 Port=4000
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2082 Port=4000
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2109 Port=4000
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>>
>>> Traceback (most recent call last):
>>> File "/usr/share/cherokee/admin/server.py", line 197, in <module>
>>> CTK.step()
>>> File "/usr/share/cherokee/admin/CTK/CTK/Server.py", line 352, in step
>>> srv._scgi.handle_request()
>>> File "/usr/lib64/python2.7/SocketServer.py", line 265, in
>>> handle_request
>>> Cherokee-admin is exiting..
>>>
>>> There is a blog article about this with a workaround for Fedora 16, but
>>> it does NOT work for me:
>>> http://michael.grunewalder.com/2011/11/25/fixing-cherokee-admin-on-fedora-16-possibly-other-distros-too/
>>>
>>> Thanks for any hints!
>>> Gregor
>>>
>>> _______________________________________________
>>> 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

Am 22.01.2012 20:30, schrieb pub crawler:
> Rabbit hole goes deeper on this one.
>
> Copied /admin/CTK directory from 1.21.xx release and placed it in
> /usr/share/cherokee/admin
>
> Now we get a different error:
>
> ImportError: No module named configured
> Traceback (most recent call last):
> File "/usr/share/cherokee/admin/server.py", line 38, in<module>
> import OWS_Login
> File "/usr/share/cherokee/admin/OWS_Login.py", line 26, in<module>
> import XMLServerDigest
> File "/usr/share/cherokee/admin/XMLServerDigest.py", line 32, in<module>
> import configured
>
> These three python files are all present where they should be...


I tried this too, and unfortunately I can only confirm similar
experiences on Fedora 16.


_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

This is interesting... I've got Cherokee 1.2.99 on a CentOS5 OpenVZ (I
think it was installed via the EPEL repository but I can't remember), and
Cherokee 1.2.100 on a Debian Linux-Vserver. Both seem to work fine for me,
including Cherokee-Admin.

[image: PageUp People]
*Daniel Lo Nigro*
Web Developer
Tel: +61 3 8677 3757


On Sun, Jan 22, 2012 at 11:49 PM, pub crawler <pubcrawler.com@gmail.com>wrote:

> Running into problems with cherokee-admin on a SolusVM / OpenVZ.
>
> Cherokee itself starts up with server reboot and functions with
> default empty configuration.
>
> cherokee-admin starts, asks for login credentials but fails to load.
>
> This is version 1.2.101, but have same experience with 1.08.xx that
> ships with Debian currently.
>
> cherokee-admin with debugging on returns:
>
> DEBUG: SIGUSR1 invokes the console..
> SIGUSR2 prints a backtrace..
> Server 1.2.101 running.. PID=26210 Port=4000
> DEBUG: SIGUSR1 invokes the console..
> SIGUSR2 prints a backtrace..
> Server 1.2.101 running.. PID=29717 Port=4000
> DEBUG: SIGUSR1 invokes the console..
> SIGUSR2 prints a backtrace..
> Server 1.2.101 running.. PID=32365 Port=4000
> DEBUG: SIGUSR1 invokes the console..
> SIGUSR2 prints a backtrace..
> Server 1.2.101 running.. PID=32150 Port=4000
> DEBUG: SIGUSR1 invokes the console..
> SIGUSR2 prints a backtrace..
> Server 1.2.101 running.. PID=3417 Port=4000
>
> Anyone have any idea on how to debug this? Has anyone seen the same
> problem?
>
> Thanks!
> _______________________________________________
> Cherokee mailing list
> Cherokee@lists.octality.com
> http://lists.octality.com/listinfo/cherokee
>

I think you guys did something really wrong...

It should run pretty fine. Does that box have ipv6 net ? Those "fixes" from
that blog seems for me 'quite bad'.

Can you please spawn the backend by hand ? And then try to run admin (it
should detect working backend and connect to it). Can you also run
cherokee-admin -x ? Also maybe try to use unix socket.


Pozdrawiam
Jędrzej Nowak


On Mon, Jan 23, 2012 at 12:07 AM, Daniel Lo Nigro <lists@dan.cx> wrote:

> This is interesting... I've got Cherokee 1.2.99 on a CentOS5 OpenVZ (I
> think it was installed via the EPEL repository but I can't remember), and
> Cherokee 1.2.100 on a Debian Linux-Vserver. Both seem to work fine for me,
> including Cherokee-Admin.
>
> [image: PageUp People]
> *Daniel Lo Nigro*
> Web Developer
> Tel: +61 3 8677 3757
>
>
> On Sun, Jan 22, 2012 at 11:49 PM, pub crawler <pubcrawler.com@gmail.com>wrote:
>
>> Running into problems with cherokee-admin on a SolusVM / OpenVZ.
>>
>> Cherokee itself starts up with server reboot and functions with
>> default empty configuration.
>>
>> cherokee-admin starts, asks for login credentials but fails to load.
>>
>> This is version 1.2.101, but have same experience with 1.08.xx that
>> ships with Debian currently.
>>
>> cherokee-admin with debugging on returns:
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 running.. PID=26210 Port=4000
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 running.. PID=29717 Port=4000
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 running.. PID=32365 Port=4000
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 running.. PID=32150 Port=4000
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 running.. PID=3417 Port=4000
>>
>> Anyone have any idea on how to debug this? Has anyone seen the same
>> problem?
>>
>> Thanks!
>> _______________________________________________
>> 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
>
>

I have cherokee-admin running with Cherokee 1.2.98 (Ubuntu 8.04) and
Cherokee 1.2.101 (Ubuntu 10.04) without problems - only the Fedora
install on my local machine does not work.


> Can you please spawn the backend by hand ? And then try to run admin (it
> should detect working backend and connect to it). Can you also run
> cherokee-admin -x ? Also maybe try to use unix socket.
>

It works when I launch "cherokee-admin -t", using a unix socket. What
does this mean?

In debug mode, I still get the following output:

Traceback (most recent call last):
File "/usr/share/cherokee/admin/CTK/CTK/XMLRPCProxy.py", line 47, in
__call__
raw = util.to_utf8 (xmlrpc_func ())
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
return self.__send(self.__name, args)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1575, in __request
verbose=self.__verbose
File "/usr/share/cherokee/admin/XMLServerDigest.py", line 145, in request
return self._request_internal (host, handler, request_body, verbose)
File "/usr/share/cherokee/admin/XMLServerDigest.py", line 140, in
_request_internal
return self._parse_response (h.getfile(), sock)
File "/usr/share/cherokee/admin/XMLServerDigest.py", line 94, in
_parse_responseWhat does this mean

return u.close()
File "/usr/lib64/python2.7/xmlrpclib.py", line 793, in close
raise Fault(**self._stack[0])
Fault: <Fault 1: 'cannot marshal None unless allow_none is enabled'>

But this is true for my two other installs as well, and does not affect
the admin's functionality - as far as I can tell.


I also added an example output from running cherokee-admin without "-t".
Here, after entering the temporary password, the browser times out:

cherokee-admin -x
[22/01/2012 13:31:59.772] (warning) rrd_tools.c:121 - Could not find the
rrdtool binary. | A custom rrdtool binary has not been defined, and the
server could not find one in the $PATH.

Cherokee Web Server 1.2.101 (Oct 19 2011): Listening on port 127.0.0.1:9090,
TLS disabled, IPv6 enabled, using epoll, 4096 fds system limit, max. 2041
connections, 2 threads, 1020 connections per thread, standard scheduling
policy

Login:
User: admin
One-time Password: 6T3TRraTb5GXwf4e

Web Interface:
URL: http://127.0.0.1:9090/

DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2079 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2082 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2109 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2113 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2117 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2131 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2135 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2138 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2141 Port=4000
DEBUG: SIGUSR1 invokes the console..
SIGUSR2 prints a backtrace..
Server 1.2.101 läuft.. PID=2144 Port=4000

Traceback (most recent call last):
File "/usr/share/cherokee/admin/server.py", line 197, in <module>
CTK.step()
File "/usr/share/cherokee/admin/CTK/CTK/Server.py", line 352, in step
srv._scgi.handle_request()
File "/usr/lib64/python2.7/SocketServer.py", line 265, in handle_request
Cherokee-admin is exiting..

_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

Does your box have ipv6 ? I made some patches for that situation but I
don't remember in what cherokee version was it included.

Pozdrawiam
Jędrzej Nowak



2012/1/23 Gregor <public@openinformation.org>:
> I have cherokee-admin running with Cherokee 1.2.98 (Ubuntu 8.04) and
> Cherokee 1.2.101 (Ubuntu 10.04) without problems - only the Fedora install
> on my local machine does not work.
>
>
>
>> Can you please spawn the backend by hand ? And then try to run admin (it
>> should detect working backend and connect to it). Can you also run
>> cherokee-admin -x ? Also maybe try to use unix socket.
>>
>
> It works when I launch "cherokee-admin -t", using a unix socket. What does
> this mean?
>
> In debug mode, I still get the following output:
>
>
> Traceback (most recent call last):
>  File "/usr/share/cherokee/admin/CTK/CTK/XMLRPCProxy.py", line 47, in
> __call__
>    raw = util.to_utf8 (xmlrpc_func ())
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
>    return self.__send(self.__name, args)
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1575, in __request
>    verbose=self.__verbose
>  File "/usr/share/cherokee/admin/XMLServerDigest.py", line 145, in request
>    return self._request_internal (host, handler, request_body, verbose)
>  File "/usr/share/cherokee/admin/XMLServerDigest.py", line 140, in
> _request_internal
>    return self._parse_response (h.getfile(), sock)
>  File "/usr/share/cherokee/admin/XMLServerDigest.py", line 94, in
> _parse_responseWhat does this mean
>
>    return u.close()
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 793, in close
>    raise Fault(**self._stack[0])
> Fault: <Fault 1: 'cannot marshal None unless allow_none is enabled'>
>
> But this is true for my two other installs as well, and does not affect the
> admin's functionality - as far as I can tell.
>
>
> I also added an example output from running cherokee-admin without "-t".
> Here, after entering the temporary password, the browser times out:
>
> cherokee-admin -x
> [22/01/2012 13:31:59.772] (warning) rrd_tools.c:121 - Could not find the
>    rrdtool binary. | A custom rrdtool binary has not been defined, and the
>    server could not find one in the $PATH.
>
> Cherokee Web Server 1.2.101 (Oct 19 2011): Listening on port 127.0.0.1:9090,
> TLS disabled, IPv6 enabled, using epoll, 4096 fds system limit, max. 2041
> connections, 2 threads, 1020 connections per thread, standard scheduling
> policy
>
> Login:
>  User:              admin
>  One-time Password: 6T3TRraTb5GXwf4e
>
> Web Interface:
>  URL:               http://127.0.0.1:9090/
>
>
> DEBUG: SIGUSR1 invokes the console..
>       SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2079 Port=4000
>
> DEBUG: SIGUSR1 invokes the console..
>       SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2082 Port=4000
>
> DEBUG: SIGUSR1 invokes the console..
>       SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2109 Port=4000
>
> DEBUG: SIGUSR1 invokes the console..
>       SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2113 Port=4000
>
> DEBUG: SIGUSR1 invokes the console..
>       SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2117 Port=4000
>
> DEBUG: SIGUSR1 invokes the console..
>       SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2131 Port=4000
>
> DEBUG: SIGUSR1 invokes the console..
>       SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2135 Port=4000
>
> DEBUG: SIGUSR1 invokes the console..
>       SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2138 Port=4000
>
> DEBUG: SIGUSR1 invokes the console..
>       SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2141 Port=4000
>
> DEBUG: SIGUSR1 invokes the console..
>       SIGUSR2 prints a backtrace..
> Server 1.2.101 läuft.. PID=2144 Port=4000
>
>
> Traceback (most recent call last):
>  File "/usr/share/cherokee/admin/server.py", line 197, in <module>
>    CTK.step()
>  File "/usr/share/cherokee/admin/CTK/CTK/Server.py", line 352, in step
>    srv._scgi.handle_request()
>  File "/usr/lib64/python2.7/SocketServer.py", line 265, in handle_request
> Cherokee-admin is exiting..
>
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

I think so - there is an ipv6 entry in hosts for the local loopback, and
as far as I know, Fedora 16 is ipv6 enabled. What do I have to check to
make sure?

Thanks!
Gregor

Am 23.01.2012 12:01, schrieb Jędrzej Nowak:
> Does your box have ipv6 ? I made some patches for that situation but I
> don't remember in what cherokee version was it included.
>
> Pozdrawiam
> Jędrzej Nowak
>
>
>
> 2012/1/23 Gregor<public@openinformation.org>:
>> I have cherokee-admin running with Cherokee 1.2.98 (Ubuntu 8.04) and
>> Cherokee 1.2.101 (Ubuntu 10.04) without problems - only the Fedora install
>> on my local machine does not work.
>>
>>
>>
>>> Can you please spawn the backend by hand ? And then try to run admin (it
>>> should detect working backend and connect to it). Can you also run
>>> cherokee-admin -x ? Also maybe try to use unix socket.
>>>
>>
>> It works when I launch "cherokee-admin -t", using a unix socket. What does
>> this mean?
>>
>> In debug mode, I still get the following output:
>>
>>
>> Traceback (most recent call last):
>> File "/usr/share/cherokee/admin/CTK/CTK/XMLRPCProxy.py", line 47, in
>> __call__
>> raw = util.to_utf8 (xmlrpc_func ())
>> File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
>> return self.__send(self.__name, args)
>> File "/usr/lib64/python2.7/xmlrpclib.py", line 1575, in __request
>> verbose=self.__verbose
>> File "/usr/share/cherokee/admin/XMLServerDigest.py", line 145, in request
>> return self._request_internal (host, handler, request_body, verbose)
>> File "/usr/share/cherokee/admin/XMLServerDigest.py", line 140, in
>> _request_internal
>> return self._parse_response (h.getfile(), sock)
>> File "/usr/share/cherokee/admin/XMLServerDigest.py", line 94, in
>> _parse_responseWhat does this mean
>>
>> return u.close()
>> File "/usr/lib64/python2.7/xmlrpclib.py", line 793, in close
>> raise Fault(**self._stack[0])
>> Fault:<Fault 1: 'cannot marshal None unless allow_none is enabled'>
>>
>> But this is true for my two other installs as well, and does not affect the
>> admin's functionality - as far as I can tell.
>>
>>
>> I also added an example output from running cherokee-admin without "-t".
>> Here, after entering the temporary password, the browser times out:
>>
>> cherokee-admin -x
>> [22/01/2012 13:31:59.772] (warning) rrd_tools.c:121 - Could not find the
>> rrdtool binary. | A custom rrdtool binary has not been defined, and the
>> server could not find one in the $PATH.
>>
>> Cherokee Web Server 1.2.101 (Oct 19 2011): Listening on port 127.0.0.1:9090,
>> TLS disabled, IPv6 enabled, using epoll, 4096 fds system limit, max. 2041
>> connections, 2 threads, 1020 connections per thread, standard scheduling
>> policy
>>
>> Login:
>> User: admin
>> One-time Password: 6T3TRraTb5GXwf4e
>>
>> Web Interface:
>> URL: http://127.0.0.1:9090/
>>
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2079 Port=4000
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2082 Port=4000
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2109 Port=4000
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2113 Port=4000
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2117 Port=4000
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2131 Port=4000
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2135 Port=4000
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2138 Port=4000
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2141 Port=4000
>>
>> DEBUG: SIGUSR1 invokes the console..
>> SIGUSR2 prints a backtrace..
>> Server 1.2.101 läuft.. PID=2144 Port=4000
>>
>>
>> Traceback (most recent call last):
>> File "/usr/share/cherokee/admin/server.py", line 197, in<module>
>> CTK.step()
>> File "/usr/share/cherokee/admin/CTK/CTK/Server.py", line 352, in step
>> srv._scgi.handle_request()
>> File "/usr/lib64/python2.7/SocketServer.py", line 265, in handle_request
>> Cherokee-admin is exiting..
>>
>

_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

Yes, this server does have IPV6. Most of mine do, however,
historically we have disabled it.

But with IPV4 IP's running out and big carriers starting to push IPV6,
we are about to see IPV6 used more widely.

On 1/23/12, Gregor <public@openinformation.org> wrote:
> I think so - there is an ipv6 entry in hosts for the local loopback, and
> as far as I know, Fedora 16 is ipv6 enabled. What do I have to check to
> make sure?
>
> Thanks!
> Gregor
>
> Am 23.01.2012 12:01, schrieb Jędrzej Nowak:
>> Does your box have ipv6 ? I made some patches for that situation but I
>> don't remember in what cherokee version was it included.
>>
>> Pozdrawiam
>> Jędrzej Nowak
>>
>>
>>
>> 2012/1/23 Gregor<public@openinformation.org>:
>>> I have cherokee-admin running with Cherokee 1.2.98 (Ubuntu 8.04) and
>>> Cherokee 1.2.101 (Ubuntu 10.04) without problems - only the Fedora
>>> install
>>> on my local machine does not work.
>>>
>>>
>>>
>>>> Can you please spawn the backend by hand ? And then try to run admin (it
>>>> should detect working backend and connect to it). Can you also run
>>>> cherokee-admin -x ? Also maybe try to use unix socket.
>>>>
>>>
>>> It works when I launch "cherokee-admin -t", using a unix socket. What
>>> does
>>> this mean?
>>>
>>> In debug mode, I still get the following output:
>>>
>>>
>>> Traceback (most recent call last):
>>> File "/usr/share/cherokee/admin/CTK/CTK/XMLRPCProxy.py", line 47, in
>>> __call__
>>> raw = util.to_utf8 (xmlrpc_func ())
>>> File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
>>> return self.__send(self.__name, args)
>>> File "/usr/lib64/python2.7/xmlrpclib.py", line 1575, in __request
>>> verbose=self.__verbose
>>> File "/usr/share/cherokee/admin/XMLServerDigest.py", line 145, in
>>> request
>>> return self._request_internal (host, handler, request_body, verbose)
>>> File "/usr/share/cherokee/admin/XMLServerDigest.py", line 140, in
>>> _request_internal
>>> return self._parse_response (h.getfile(), sock)
>>> File "/usr/share/cherokee/admin/XMLServerDigest.py", line 94, in
>>> _parse_responseWhat does this mean
>>>
>>> return u.close()
>>> File "/usr/lib64/python2.7/xmlrpclib.py", line 793, in close
>>> raise Fault(**self._stack[0])
>>> Fault:<Fault 1: 'cannot marshal None unless allow_none is enabled'>
>>>
>>> But this is true for my two other installs as well, and does not affect
>>> the
>>> admin's functionality - as far as I can tell.
>>>
>>>
>>> I also added an example output from running cherokee-admin without "-t".
>>> Here, after entering the temporary password, the browser times out:
>>>
>>> cherokee-admin -x
>>> [22/01/2012 13:31:59.772] (warning) rrd_tools.c:121 - Could not find the
>>> rrdtool binary. | A custom rrdtool binary has not been defined, and
>>> the
>>> server could not find one in the $PATH.
>>>
>>> Cherokee Web Server 1.2.101 (Oct 19 2011): Listening on port
>>> 127.0.0.1:9090,
>>> TLS disabled, IPv6 enabled, using epoll, 4096 fds system limit, max. 2041
>>> connections, 2 threads, 1020 connections per thread, standard scheduling
>>> policy
>>>
>>> Login:
>>> User: admin
>>> One-time Password: 6T3TRraTb5GXwf4e
>>>
>>> Web Interface:
>>> URL: http://127.0.0.1:9090/
>>>
>>>
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2079 Port=4000
>>>
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2082 Port=4000
>>>
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2109 Port=4000
>>>
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2113 Port=4000
>>>
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2117 Port=4000
>>>
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2131 Port=4000
>>>
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2135 Port=4000
>>>
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2138 Port=4000
>>>
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2141 Port=4000
>>>
>>> DEBUG: SIGUSR1 invokes the console..
>>> SIGUSR2 prints a backtrace..
>>> Server 1.2.101 läuft.. PID=2144 Port=4000
>>>
>>>
>>> Traceback (most recent call last):
>>> File "/usr/share/cherokee/admin/server.py", line 197, in<module>
>>> CTK.step()
>>> File "/usr/share/cherokee/admin/CTK/CTK/Server.py", line 352, in step
>>> srv._scgi.handle_request()
>>> File "/usr/lib64/python2.7/SocketServer.py", line 265, in
>>> handle_request
>>> Cherokee-admin is exiting..
>>>
>>
>
> _______________________________________________
> 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

Are the IPV6 patches mentioned being included in latest source releases?

On 1/23/12, pub crawler <pubcrawler.com@gmail.com> wrote:
> Yes, this server does have IPV6. Most of mine do, however,
> historically we have disabled it.
>
> But with IPV4 IP's running out and big carriers starting to push IPV6,
> we are about to see IPV6 used more widely.
>
> On 1/23/12, Gregor <public@openinformation.org> wrote:
>> I think so - there is an ipv6 entry in hosts for the local loopback, and
>> as far as I know, Fedora 16 is ipv6 enabled. What do I have to check to
>> make sure?
>>
>> Thanks!
>> Gregor
>>
>> Am 23.01.2012 12:01, schrieb Jędrzej Nowak:
>>> Does your box have ipv6 ? I made some patches for that situation but I
>>> don't remember in what cherokee version was it included.
>>>
>>> Pozdrawiam
>>> Jędrzej Nowak
>>>
>>>
>>>
>>> 2012/1/23 Gregor<public@openinformation.org>:
>>>> I have cherokee-admin running with Cherokee 1.2.98 (Ubuntu 8.04) and
>>>> Cherokee 1.2.101 (Ubuntu 10.04) without problems - only the Fedora
>>>> install
>>>> on my local machine does not work.
>>>>
>>>>
>>>>
>>>>> Can you please spawn the backend by hand ? And then try to run admin
>>>>> (it
>>>>> should detect working backend and connect to it). Can you also run
>>>>> cherokee-admin -x ? Also maybe try to use unix socket.
>>>>>
>>>>
>>>> It works when I launch "cherokee-admin -t", using a unix socket. What
>>>> does
>>>> this mean?
>>>>
>>>> In debug mode, I still get the following output:
>>>>
>>>>
>>>> Traceback (most recent call last):
>>>> File "/usr/share/cherokee/admin/CTK/CTK/XMLRPCProxy.py", line 47, in
>>>> __call__
>>>> raw = util.to_utf8 (xmlrpc_func ())
>>>> File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
>>>> return self.__send(self.__name, args)
>>>> File "/usr/lib64/python2.7/xmlrpclib.py", line 1575, in __request
>>>> verbose=self.__verbose
>>>> File "/usr/share/cherokee/admin/XMLServerDigest.py", line 145, in
>>>> request
>>>> return self._request_internal (host, handler, request_body,
>>>> verbose)
>>>> File "/usr/share/cherokee/admin/XMLServerDigest.py", line 140, in
>>>> _request_internal
>>>> return self._parse_response (h.getfile(), sock)
>>>> File "/usr/share/cherokee/admin/XMLServerDigest.py", line 94, in
>>>> _parse_responseWhat does this mean
>>>>
>>>> return u.close()
>>>> File "/usr/lib64/python2.7/xmlrpclib.py", line 793, in close
>>>> raise Fault(**self._stack[0])
>>>> Fault:<Fault 1: 'cannot marshal None unless allow_none is enabled'>
>>>>
>>>> But this is true for my two other installs as well, and does not affect
>>>> the
>>>> admin's functionality - as far as I can tell.
>>>>
>>>>
>>>> I also added an example output from running cherokee-admin without
>>>> "-t".
>>>> Here, after entering the temporary password, the browser times out:
>>>>
>>>> cherokee-admin -x
>>>> [22/01/2012 13:31:59.772] (warning) rrd_tools.c:121 - Could not find
>>>> the
>>>> rrdtool binary. | A custom rrdtool binary has not been defined, and
>>>> the
>>>> server could not find one in the $PATH.
>>>>
>>>> Cherokee Web Server 1.2.101 (Oct 19 2011): Listening on port
>>>> 127.0.0.1:9090,
>>>> TLS disabled, IPv6 enabled, using epoll, 4096 fds system limit, max.
>>>> 2041
>>>> connections, 2 threads, 1020 connections per thread, standard
>>>> scheduling
>>>> policy
>>>>
>>>> Login:
>>>> User: admin
>>>> One-time Password: 6T3TRraTb5GXwf4e
>>>>
>>>> Web Interface:
>>>> URL: http://127.0.0.1:9090/
>>>>
>>>>
>>>> DEBUG: SIGUSR1 invokes the console..
>>>> SIGUSR2 prints a backtrace..
>>>> Server 1.2.101 läuft.. PID=2079 Port=4000
>>>>
>>>> DEBUG: SIGUSR1 invokes the console..
>>>> SIGUSR2 prints a backtrace..
>>>> Server 1.2.101 läuft.. PID=2082 Port=4000
>>>>
>>>> DEBUG: SIGUSR1 invokes the console..
>>>> SIGUSR2 prints a backtrace..
>>>> Server 1.2.101 läuft.. PID=2109 Port=4000
>>>>
>>>> DEBUG: SIGUSR1 invokes the console..
>>>> SIGUSR2 prints a backtrace..
>>>> Server 1.2.101 läuft.. PID=2113 Port=4000
>>>>
>>>> DEBUG: SIGUSR1 invokes the console..
>>>> SIGUSR2 prints a backtrace..
>>>> Server 1.2.101 läuft.. PID=2117 Port=4000
>>>>
>>>> DEBUG: SIGUSR1 invokes the console..
>>>> SIGUSR2 prints a backtrace..
>>>> Server 1.2.101 läuft.. PID=2131 Port=4000
>>>>
>>>> DEBUG: SIGUSR1 invokes the console..
>>>> SIGUSR2 prints a backtrace..
>>>> Server 1.2.101 läuft.. PID=2135 Port=4000
>>>>
>>>> DEBUG: SIGUSR1 invokes the console..
>>>> SIGUSR2 prints a backtrace..
>>>> Server 1.2.101 läuft.. PID=2138 Port=4000
>>>>
>>>> DEBUG: SIGUSR1 invokes the console..
>>>> SIGUSR2 prints a backtrace..
>>>> Server 1.2.101 läuft.. PID=2141 Port=4000
>>>>
>>>> DEBUG: SIGUSR1 invokes the console..
>>>> SIGUSR2 prints a backtrace..
>>>> Server 1.2.101 läuft.. PID=2144 Port=4000
>>>>
>>>>
>>>> Traceback (most recent call last):
>>>> File "/usr/share/cherokee/admin/server.py", line 197, in<module>
>>>> CTK.step()
>>>> File "/usr/share/cherokee/admin/CTK/CTK/Server.py", line 352, in step
>>>> srv._scgi.handle_request()
>>>> File "/usr/lib64/python2.7/SocketServer.py", line 265, in
>>>> handle_request
>>>> Cherokee-admin is exiting..
>>>>
>>>
>>
>> _______________________________________________
>> 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 Sun, Jan 22, 2012 at 12:22 PM, pub crawler <pubcrawler.com@gmail.com>wrote:

>
> Now, the source I used for this from GIT, using the download of a zip
> file. Did this today, so current.
>
> Under /admin directory in this zipfile I do see a CTK subdirectory,
> but it is empty...


The empty CTK directory is an issue with how github.com handles git
submodules referenced in a project. If you checkout the repo directly
using --recursive (or `git submodule update --init` after pulling down the
initial repo) the submodule in question (CTK) will be present and
available. At present time the zip/tarball that's auto-generated by github
doesn't recursively included any of the referenced submodules which is the
reason for the empty directory.

As it relates to direct downloads of the auto-generated zip/tarball, unless
github chooses to recursively include references submodules, this will
continue to be a problem us. The workaround is to check the CTK folder for
the existence of the source files and, if not present, pull down and
extract the auto-generated zip/tarball for the CTK project from github
before continuing the build process.

This won't work for folks building on machines without Internet access, but
we can provide a developer-friendly error specifying the need to download
and extract the proper CTK archive before continuing the build.

Alvaro: I'll take a look at adding this functionality to the Makefile of
the master branch later this evening. I'll ping back when ready for review.

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

Can you share the recommended way to get latest complete source from Git?

We need to update the docs with clear how-to on this. Can't find
such in the documentation.

Thanks!

On 1/23/12, M. David Peterson <m.david@3rdandurban.com> wrote:
> On Sun, Jan 22, 2012 at 12:22 PM, pub crawler
> <pubcrawler.com@gmail.com>wrote:
>
>>
>> Now, the source I used for this from GIT, using the download of a zip
>> file. Did this today, so current.
>>
>> Under /admin directory in this zipfile I do see a CTK subdirectory,
>> but it is empty...
>
>
> The empty CTK directory is an issue with how github.com handles git
> submodules referenced in a project. If you checkout the repo directly
> using --recursive (or `git submodule update --init` after pulling down the
> initial repo) the submodule in question (CTK) will be present and
> available. At present time the zip/tarball that's auto-generated by github
> doesn't recursively included any of the referenced submodules which is the
> reason for the empty directory.
>
> As it relates to direct downloads of the auto-generated zip/tarball, unless
> github chooses to recursively include references submodules, this will
> continue to be a problem us. The workaround is to check the CTK folder for
> the existence of the source files and, if not present, pull down and
> extract the auto-generated zip/tarball for the CTK project from github
> before continuing the build process.
>
> This won't work for folks building on machines without Internet access, but
> we can provide a developer-friendly error specifying the need to download
> and extract the proper CTK archive before continuing the build.
>
> Alvaro: I'll take a look at adding this functionality to the Makefile of
> the master branch later this evening. I'll ping back when ready for review.
>
> --
> /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 Mon, Jan 23, 2012 at 3:55 PM, pub crawler <pubcrawler.com@gmail.com>wrote:

> Can you share the recommended way to get latest complete source from Git?
>

Depending on your definition of "latest" (latest unreleased development,
latest tagged release, latest commit to the master branch) you'll first
need to clone the /cherokee/webserver repository with the --recursive
option and then switch (if necessary) to the desired dev branch. So:

git clone git://github.com/cherokee/webserver.git --recursive

... will clone the webserver repo and the repo's of all submodules. Your
local copy will have the master branch checked out and whichever sha1
commit of the related submodules was last specified for that branch. The
master branch is a few commits ahead of the v1.2.101 tag, but as far as I
know the commits don't represent changes to the working code, though I'll
need to verify. Either way, to checkout the latest official release
(v1.2.101):

git checkout -b [local_branch_name] v1.2.101

... will checkout the latest tagged release using whatever name you chose
as the name of the local branch (which can be the same as the tag name if
you want). If you don't necessarily need a local branch to work from (hack
on code, commit locally, push to remote repo) you can simply run:

git checkout v1.2.101

... which will leave your local repository in a detached HEAD state which
is fine if you have no plans to make changes to the code base that needs to
tracked as part of a specific branch. If you do make changes that need to
be tracked as part of a branch you can run:

git checkout -b [local_branch_name]

... when in the detached head state. Any commits you've already made and
all future commits made while you have this branch checked out will be
tracked by that branch which you can then merge into another branch when
ready and/or push to a remote repo.

Alvaro will need to comment on which of the development (SPDY, dev, or
new-events) branches represents his current workflow, but my assumption is
that the dev branch is where all of the other branches have or will get
merged into. So to switch to the bleeding edge:

git checkout -b [local_branch_name] dev

With all of the above you'll want need to run:

git submodule update

... to ensure all submodules match the sha1 committed to the index for the
related branch.

We need to update the docs with clear how-to on this. Can't find
> such in the documentation.
>

Agreed. I'll add it to my task list, though can you specify whether the
above adequately answers your question?

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

Thanks Mr. Peterson for taking the time to share how us less technical
folks use git :)

Still foggy :)

When my evening quiets down I'll give it a spin and see what this yields.

Looks like (in part) what needs amended to the docs. Still
prominently telling one to use SVN for latest source (even in git web
interface main screen).

Bunch of stuff like that outstanding. Glad to help cleanup the
documentation and amend this type of info if technically knowledgeable
folks share the details.

On 1/23/12, M. David Peterson <m.david@3rdandurban.com> wrote:
> On Mon, Jan 23, 2012 at 3:55 PM, pub crawler
> <pubcrawler.com@gmail.com>wrote:
>
>> Can you share the recommended way to get latest complete source from Git?
>>
>
> Depending on your definition of "latest" (latest unreleased development,
> latest tagged release, latest commit to the master branch) you'll first
> need to clone the /cherokee/webserver repository with the --recursive
> option and then switch (if necessary) to the desired dev branch. So:
>
> git clone git://github.com/cherokee/webserver.git --recursive
>
> ... will clone the webserver repo and the repo's of all submodules. Your
> local copy will have the master branch checked out and whichever sha1
> commit of the related submodules was last specified for that branch. The
> master branch is a few commits ahead of the v1.2.101 tag, but as far as I
> know the commits don't represent changes to the working code, though I'll
> need to verify. Either way, to checkout the latest official release
> (v1.2.101):
>
> git checkout -b [local_branch_name] v1.2.101
>
> ... will checkout the latest tagged release using whatever name you chose
> as the name of the local branch (which can be the same as the tag name if
> you want). If you don't necessarily need a local branch to work from (hack
> on code, commit locally, push to remote repo) you can simply run:
>
> git checkout v1.2.101
>
> ... which will leave your local repository in a detached HEAD state which
> is fine if you have no plans to make changes to the code base that needs to
> tracked as part of a specific branch. If you do make changes that need to
> be tracked as part of a branch you can run:
>
> git checkout -b [local_branch_name]
>
> ... when in the detached head state. Any commits you've already made and
> all future commits made while you have this branch checked out will be
> tracked by that branch which you can then merge into another branch when
> ready and/or push to a remote repo.
>
> Alvaro will need to comment on which of the development (SPDY, dev, or
> new-events) branches represents his current workflow, but my assumption is
> that the dev branch is where all of the other branches have or will get
> merged into. So to switch to the bleeding edge:
>
> git checkout -b [local_branch_name] dev
>
> With all of the above you'll want need to run:
>
> git submodule update
>
> ... to ensure all submodules match the sha1 committed to the index for the
> related branch.
>
> We need to update the docs with clear how-to on this. Can't find
>> such in the documentation.
>>
>
> Agreed. I'll add it to my task list, though can you specify whether the
> above adequately answers your question?
>
> --
> /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

Alright, stole a few minutes to give this a spin.

Wanting to accomplish git was I would with svn in the past. Fetching
the latest development release for testing.

Did this:

git clone git://github.com/cherokee/webserver.git --recursive

That ran fine. New subdirectory called webserver

cd webserver

more README

Started the default compile instructions:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var

That returns:
./configure: No such file or directory

So, how do I fix this up so we can compile?

On 1/23/12, pub crawler <pubcrawler.com@gmail.com> wrote:
> Thanks Mr. Peterson for taking the time to share how us less technical
> folks use git :)
>
> Still foggy :)
>
> When my evening quiets down I'll give it a spin and see what this yields.
>
> Looks like (in part) what needs amended to the docs. Still
> prominently telling one to use SVN for latest source (even in git web
> interface main screen).
>
> Bunch of stuff like that outstanding. Glad to help cleanup the
> documentation and amend this type of info if technically knowledgeable
> folks share the details.
>
> On 1/23/12, M. David Peterson <m.david@3rdandurban.com> wrote:
>> On Mon, Jan 23, 2012 at 3:55 PM, pub crawler
>> <pubcrawler.com@gmail.com>wrote:
>>
>>> Can you share the recommended way to get latest complete source from
>>> Git?
>>>
>>
>> Depending on your definition of "latest" (latest unreleased development,
>> latest tagged release, latest commit to the master branch) you'll first
>> need to clone the /cherokee/webserver repository with the --recursive
>> option and then switch (if necessary) to the desired dev branch. So:
>>
>> git clone git://github.com/cherokee/webserver.git --recursive
>>
>> ... will clone the webserver repo and the repo's of all submodules. Your
>> local copy will have the master branch checked out and whichever sha1
>> commit of the related submodules was last specified for that branch. The
>> master branch is a few commits ahead of the v1.2.101 tag, but as far as I
>> know the commits don't represent changes to the working code, though I'll
>> need to verify. Either way, to checkout the latest official release
>> (v1.2.101):
>>
>> git checkout -b [local_branch_name] v1.2.101
>>
>> ... will checkout the latest tagged release using whatever name you chose
>> as the name of the local branch (which can be the same as the tag name if
>> you want). If you don't necessarily need a local branch to work from
>> (hack
>> on code, commit locally, push to remote repo) you can simply run:
>>
>> git checkout v1.2.101
>>
>> ... which will leave your local repository in a detached HEAD state which
>> is fine if you have no plans to make changes to the code base that needs
>> to
>> tracked as part of a specific branch. If you do make changes that need
>> to
>> be tracked as part of a branch you can run:
>>
>> git checkout -b [local_branch_name]
>>
>> ... when in the detached head state. Any commits you've already made and
>> all future commits made while you have this branch checked out will be
>> tracked by that branch which you can then merge into another branch when
>> ready and/or push to a remote repo.
>>
>> Alvaro will need to comment on which of the development (SPDY, dev, or
>> new-events) branches represents his current workflow, but my assumption
>> is
>> that the dev branch is where all of the other branches have or will get
>> merged into. So to switch to the bleeding edge:
>>
>> git checkout -b [local_branch_name] dev
>>
>> With all of the above you'll want need to run:
>>
>> git submodule update
>>
>> ... to ensure all submodules match the sha1 committed to the index for
>> the
>> related branch.
>>
>> We need to update the docs with clear how-to on this. Can't find
>>> such in the documentation.
>>>
>>
>> Agreed. I'll add it to my task list, though can you specify whether the
>> above adequately answers your question?
>>
>> --
>> /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 Mon, Jan 23, 2012 at 5:51 PM, pub crawler <pubcrawler.com@gmail.com>wrote:

> Started the default compile instructions:
> ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
>
> That returns:
> ./configure: No such file or directory
>
> So, how do I fix this up so we can compile?
>

The bare repository doesn't contain the auto-generated configure script,
only the configuration files that are used to generate the configure
script. To fix this run autogen.sh with the same parameters which will
auto-generate the configure script and then run the configure script with
the specified variables. e.g.

./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var

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