pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[DME]

Old certs (including ca.crt/ca.key) need to be readable by 'nobody'. Change them to owner 'nobody' will do.

Another option is to remove all generated certs in the dir. Then they'll be automatically re-generated on demand with owner 'nobody'.

I did a fresh install of ab-solution and pixelserv. Every thing worked great. When I checked the ownership of the certs, ca.crt and ca.key belonged to the router, the others to nobody. I did change the ownership of ca.crt and ca.key to nobody. Everything is still working great. Is it a problem not to change the ownership.?

 

[thelonelycoder]

Is it a problem not to change the ownership.?

It's not a problem for the two cert files to be owned by the admin user.
They were generated by AB-Solution during the install. The owner is set by the user calling the certificate creation-script, which is the admin user when installing through AB-Solution.
All certs generated by pixelserv-tls are owned by "nobody" and is fine too.
Unless proven otherwise, leave it as is.

 

[kvic]

it got restarted when my lists update on sundays.

Work always take the priority of course. Is it your practice to restart on a weekly basis? Frankly I don't like the idea. You shall leave pixelserv-tls running as long as you could.

I think it'll stuck eventually. The process is not dead but the socket won't respond. I suspect it's kernel issue on old routers like 56U. But that's after 18million requests served in my stress test on an earlier test version of KL.

 

[jrmwvu04]

Users may not be aware of that change and there's no conclusive error output in the Syslog if it fails to start because of a wrong logging setting.

That makes sense.

 

[kvic]

8a was OK. 8b looks to have a problem with the kvg counter; shouldn't be less than 1:

pixelserv-tls: v35.HZ12.Kl-test8b compiled: Nov 19 2017 08:47:07 options: 192.168.0.201

uts 0d 00:05 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 1 number of active service threads
kmx 40 maximum number of service threads
kvg 0.63 average number of requests per service thread
krq 5 max number of requests by one service thread
req 127 total # of requests (HTTP, HTTPS, success, failure etc)
avg 728 bytes average size of requests
rmx 1802 bytes largest size of request(s)
tav 19 ms average processing time (per request)
tmx 101 ms longest processing time (per request)

After 7 hours of use:

Thanks for the stats! I realised from your stats that the counters still have issues, and fixed in 8c. Pls let me know if they still don't look right.

 

[kvic]

Up 15:20 with 2900 requests, tav is 3ms.

Having a faster router seems really help. Mine is around 60ms now (yeah!) with mostly requests from WAN. Will drift to around 25ms when mostly from LAN.

Thanks for the list. I'm going to give it a run.

 

[Raphie]

Thanks for the stats! I realised from your stats that the counters still have issues, and fixed in 8c. Pls let me know if they still don't look right.

@kvic more stats

pixelserv-tls: v35.HZ12.Kl-test8c compiled: Nov 20 2017 11:07:00 options: 192.168.1.2

uts 0d 05:32 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 1 number of active service threads
kmx 4 maximum number of service threads
kvg 1.89 average number of requests per service thread
krq 3 max number of requests by one service thread
req 2527 total # of requests (HTTP, HTTPS, success, failure etc)
avg 328 bytes average size of requests
rmx 1320 bytes largest size of request(s)
tav 10 ms average processing time (per request)
tmx 461 ms longest processing time (per request)
slh 0 # of accepted HTTPS requests
slm 4 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 1794 # of dropped HTTPS requests (client disconnect without sending any request)
slu 12 # of dropped HTTPS requests (unknown error)
nfe 122 # of GET requests for server-side scripting
gif 0 # of GET requests for GIF
ico 0 # of GET requests for ICO
txt 3 # of GET requests for Javascripts
jpg 0 # of GET requests for JPG
png 0 # of GET requests for PNG
swf 0 # of GET requests for SWF
sta 3 # of GET requests for HTML stats
stt 2 # of GET requests for plain text stats
ufe 0 # of GET requests /w unknown file extension
opt 0 # of OPTIONS requests
pst 1 # of POST requests
hed 0 # of HEAD requests (HTTP 501 response)
rdr 4 # of GET requests resulted in REDIRECT response
nou 0 # of GET requests /w empty URL
pth 0 # of GET requests /w malformed URL
204 0 # of GET requests (HTTP 204 response)
bad 0 # of unknown HTTP requests (HTTP 501 response)
tmo 1 # of timeout requests (client connect w/o sending a request in 'select_timeout' secs)
cls 1800 # of dropped requests (client disconnect without sending any request)
cly 0 # of dropped requests (client disconnect before response sent)
clt 0 # of dropped requests (reached maximum service threads)
err 0 # of dropped requests (unknown reason)

 

[kvic]

Uploaded KL-test8d

Change: Keep CLI option '-l' without level for backward compatibility.

If you have KL-test8c running well, you perhaps shall keep it running for as long as it can.

 

[Raphie]

Ok I’ll keep this one on for at least the next 24h

 

[Protik]

Thanks for letting me know. That's a glitch in the install-beta.sh script (v0.1.1).

Now is fixed (in v0.1.2). To solve the problem:

1. stop pixelserv-tls first by:

/opt/etc/init.d/S80pixelserv-tls stop

2. then re-run the install-beta.sh script, and restart pixelserv-tls

That fixed it. Thanks!

 

[elorimer]

Updated to 8c using update script 0.1.2, no issues. Counters look good after almost 11 hours:

uts 0d 10:34 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 1 number of active service threads
kmx 30 maximum number of service threads
kvg 2.02 average number of requests per service thread
krq 21 max number of requests by one service thread
req 6161 total # of requests (HTTP, HTTPS, success, failure etc)
avg 1129 bytes average size of requests
rmx 20061 bytes largest size of request(s)
tav 19 ms average processing time (per request)
tmx 3218 ms longest processing time (per request)

 

[Raphie]

1 day status

pixelserv-tls: v35.HZ12.Kl-test8c compiled: Nov 20 2017 11:07:00 options: 192.168.1.2

uts 1d 00:03 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 1 number of active service threads
kmx 15 maximum number of service threads
kvg 1.90 average number of requests per service thread
krq 7 max number of requests by one service thread
req 10769 total # of requests (HTTP, HTTPS, success, failure etc)
avg 422 bytes average size of requests
rmx 7882 bytes largest size of request(s)
tav 12 ms average processing time (per request)
tmx 671 ms longest processing time (per request)
slh 0 # of accepted HTTPS requests
slm 4 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 3588 # of dropped HTTPS requests (client disconnect without sending any request)
slu 131 # of dropped HTTPS requests (unknown error)
nfe 246 # of GET requests for server-side scripting
gif 1 # of GET requests for GIF
ico 0 # of GET requests for ICO
txt 31 # of GET requests for Javascripts
jpg 8 # of GET requests for JPG
png 0 # of GET requests for PNG
swf 0 # of GET requests for SWF
sta 6 # of GET requests for HTML stats
stt 2 # of GET requests for plain text stats
ufe 2 # of GET requests /w unknown file extension
opt 0 # of OPTIONS requests
pst 21 # of POST requests
hed 0 # of HEAD requests (HTTP 501 response)
rdr 52 # of GET requests resulted in REDIRECT response
nou 0 # of GET requests /w empty URL
pth 0 # of GET requests /w malformed URL
204 0 # of GET requests (HTTP 204 response)
bad 0 # of unknown HTTP requests (HTTP 501 response)
tmo 3 # of timeout requests (client connect w/o sending a request in 'select_timeout' secs)
cls 3610 # of dropped requests (client disconnect without sending any request)
cly 0 # of dropped requests (client disconnect before response sent)
clt 0 # of dropped requests (reached maximum service threads)
err 0 # of dropped requests (unknown reason)

 

[kvic]

req 10769 total # of requests (HTTP, HTTPS, success, failure etc)
slh 0 # of accepted HTTPS requests
slm 4 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 3588 # of dropped HTTPS requests (client disconnect without sending any request)
slu 131 # of dropped HTTPS requests (unknown error)

'req' is the total number of requests received by pixelserv-tls.
'slh' is the number of successful HTTPS requests.

A 0 'slh' and a large 'slc' indicate clients haven't imported the CA certificate.

This is fine though I would recommend importing the CA certificate on your commonly used clients if possible. And it's easy! Here are the tutorials.

@Raphie

So your next step is to find some time and experiment with importing the CA certificate on your phone.

 

[kvic]

When I checked the ownership of the certs, ca.crt and ca.key belonged to the router, the others to nobody. I did change the ownership of ca.crt and ca.key to nobody. Everything is still working great. Is it a problem not to change the ownership.?

This is all fine, and thanks for raising the question.

Together with the coming KL release, I'll submit a change to Entware so that the owner of the certificate directory will default to 'nobody'.

That'll make hassle free for everyone.

 

[jrmwvu04]

A 0 'slh' and a large 'slc' indicate clients haven't imported the CA certificate.

I noticed that as well. @Raphie - If it isn't too much trouble, you'll get a performance increase and eliminate a lot of browser nags about invalid certificates if you take the time to do the imports.

Together with the coming KL release, I'll submit a change to Entware so that the owner of the certificate directory will default to 'nobody'.

Without going too far down a complicated path, what's the functional difference between pixelserv-tls running as nobody versus admin?

Decided to throw test8d on since I'm flashing 28E8. Seeing really aggressive performance gains over even the earlier Kl test builds. Impressive how this is improving.

 

[thelonelycoder]

Together with the coming KL release, I'll submit a change to Entware so that the owner of the certificate directory will default to 'nobody'.

In AB-Solution, this is done during install. And later checked again.

 

[Protik]

req 10769 total # of requests (HTTP, HTTPS, success, failure etc)
slh 0 # of accepted HTTPS requests
slm 4 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 3588 # of dropped HTTPS requests (client disconnect without sending any request)
slu 131 # of dropped HTTPS requests (unknown error)

'req' is the total number of requests received by pixelserv-tls.
'slh' is the number of successful HTTPS requests.

A 0 'slh' and a large 'slc' indicate clients haven't imported the CA certificate.

This is fine though I would recommend importing the CA certificate on your commonly used clients if possible. And it's easy! Here are the tutorials.

@Raphie

So your next step is to find some time and experiment with importing the CA certificate on your phone.

In my case the slh was only 2 and slc was more than 1000. So I followed the tutorial and imported ca.crt into my firefox, windows machine and android phone. But the slc was still increasing without any effect on slh.

I tried restarting browser, windows machine and pixelserv service. But still the slc keeps increasing. My opt/var/cache/pixelserv/ reads:

-rw- rw- rw-    1 ad min    ro ot           802 Nov 21 10:07 ca . crt
-rw- rw- rw-    1 ad min    ro ot           887 Nov 21 10:05 ca . key

Any idea about what I did wrong?

 

[elorimer]

Hmm. I think I've done something wrong too:

uts 1d 10:39 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 19 number of active service threads
kmx 30 maximum number of service threads
kvg 1.99 average number of requests per service thread
krq 21 max number of requests by one service thread
req 12930 total # of requests (HTTP, HTTPS, success, failure etc)
avg 947 bytes average size of requests
rmx 20682 bytes largest size of request(s)
tav 21 ms average processing time (per request)
tmx 3218 ms longest processing time (per request)
slh 0 # of accepted HTTPS requests
slm 11 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 10153 # of dropped HTTPS requests (client disconnect without sending any request)
slu 3 # of dropped HTTPS requests (unknown error)

I have imported the cert into Windows using the Comodo guide (it leaves out the fact that you need to run MMC as administrator). I haven't imported it on all the machines, but slh shouldn't be 0.

 

[kvic]

@jrmwvu04

KL test works very well in your environment. A 'kvg' of 4.53 is far more efficient than mine. I'm ascending slowly and currently near 1.99. On the same test8c build.

Without going too far down a complicated path, what's the functional difference between pixelserv-tls running as nobody versus admin?

With 'nobody', someone hack into pixelserv-tls process will be jailed and can do no evil. With 'admin', the hacker will be able to get a shell and have the power of 'root' user.

However, pixelserv-tls is not recommended for directly facing the WAN. So such incidence is very unlikely to happen.

 

[kvic]

@Protik @elorimer

I suspect the CA certificate has issue in your cases. Can you try following the instruction in the same tutorial:

1. clean up everything in /opt/var/cache/pixelserv
2. follow the tutorial to generate the CA certificate
3. restart pixelserv-tls (/opt/etc/init.d/S80pixelserv-tls restart)
4. import the new CA cert into a client