Re: Need assistance debugging Squid error: ssl_ctrd helpers crashing too quickly

[Yuri <yvoinov@xxxxxxxxx>]

Seems latest 4.0.21 is good enough. Most critical SSL-related bugs almost closed or closed.

At least latest 3.5.27 is released. AFAIK this is minimum to problem-free running.

Repositories software sometimes has strange quirks, or sometimes rancid.

12.09.2017 2:05, Rohit Sodhia пишет:

I'll try to find it, but I read a few articles/SO questions that suggested there were bugs in 4 relating to SSL bumping? If they were wrong, I'd be glad to go forward. Should I be removing the yum squid package and compile my own? Is 3.5 problematic besides being old?

On Mon, Sep 11, 2017 at 4:02 PM, Yuri <yvoinov@xxxxxxxxx> wrote:

Wait. Squid 3.5.20? So ancient?

12.09.2017 1:58, Rohit Sodhia пишет:

sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB

I used the line from the Stack Overflow question I linked earlier.

On Mon, Sep 11, 2017 at 3:41 PM, Yuri <yvoinov@xxxxxxxxx> wrote:

Well. Let's check more deep.

Show me parameter sslcrtd_program in your squid.conf

12.09.2017 1:23, Rohit Sodhia пишет:

Unfortunately, no luck yet. Thank you again for your help before.

I found that the user squid and group squid existed already, so I added

cache_effective_user squid
cache_effective_group squid

to my config (first two lines), made sure /var/lib/ssl_db and it's contents were set to squid:squid and restarted the service, but I'm still getting the same error :(

On Mon, Sep 11, 2017 at 2:42 PM, Rohit Sodhia <sodhia.rohit@xxxxxxxxx> wrote:

I'll try that immediately, thanks! I appreciate all your advice; hopefully I won't have to reach out again :p

On Mon, Sep 11, 2017 at 2:39 PM, Yuri <yvoinov@xxxxxxxxx> wrote:

I'm not Linux fanboy, but modern squid never runs as root. So, most probably it runs as nobody user.

Ah, yes:

#  TAG: cache_effective_user
#    If you start Squid as root, it will change its effective/real
#    UID/GID to the user specified below.  The default is to change
#    to UID of nobody.
#    see also; cache_effective_group
#Default:
# cache_effective_user nobody

#  TAG: cache_effective_group
#    Squid sets the GID to the effective user's default group ID
#    (taken from the password file) and supplementary group list
#    from the groups membership.
#
#    If you want Squid to run with a specific GID regardless of
#    the group memberships of the effective user then set this
#    to the group (or GID) you want Squid to run as. When set
#    all other group privileges of the effective user are ignored
#    and only this GID is effective. If Squid is not started as
#    root the user starting Squid MUST be member of the specified
#    group.
#
#    This option is not recommended by the Squid Team.
#    Our preference is for administrators to configure a secure
#    user account for squid with UID/GID matching system policies.
#Default:
# Use system group memberships of the cache_effective_user account

As documented. :)

AFAIK best solution is create non-privileged group & user (like squid/squid) and set both this parameters explicity.

Then change owner recursively on SSL cache to this user.

12.09.2017 0:36, Rohit Sodhia пишет:

Neither of those values are set in my config. Even though I'm not using squid for caching, I need those values? They aren't set in the default configs either.

On Mon, Sep 11, 2017 at 2:33 PM, Yuri <yvoinov@xxxxxxxxx> wrote:

Most probably you squid runs as another user than squid.

Check your squid.conf for cache_effective_user and cache_effective_group values.

Then change SSL cache permissions to this values. Should work.

12.09.2017 0:30, Rohit Sodhia пишет:

Thanks for the feedback! I just used yum (it's a CentOS 7 VB) and it set it up like that. I changed the owner and group to squid:squid and tried restarting squid, but still get the same errors. I thought to run the command again, but this time it says

/usr/lib64/squid/ssl_crtd: Cannot create /var/lib/ssl_db

If this folder has incorrect permissions are there possibly other permission issues?

On Mon, Sep 11, 2017 at 2:25 PM, Yuri <yvoinov@xxxxxxxxx> wrote:

Here you root of problem.

Should be (on my setups):

# ls -al /var/lib/ssl_db
total 326
drwxr-xr-x 3 squid squid      5 Sep  5 00:53 .
drwxr-xr-x 8 root  other      8 Sep  5 00:53 ..
drwxr-xr-x 2 squid squid    454 Sep 11 23:37 certs
-rw-r--r-- 1 squid squid 280575 Sep 11 23:37 index.txt
-rw-r--r-- 1 squid squid      7 Sep 11 23:37 size

I.e. Squid has no access to SSL cache dir structures.

12.09.2017 0:23, Rohit Sodhia пишет:

total 8
drwxr-xr-x.  3 root root   48 Sep 11 12:42 .
drwxr-xr-x. 32 root root 4096 Sep 11 12:42 ..
drwxr-xr-x.  2 root root    6 Sep 11 12:42 certs
-rw-r--r--.  1 root root    0 Sep 11 12:42 index.txt
-rw-r--r--.  1 root root    1 Sep 11 12:42 size

On Mon, Sep 11, 2017 at 2:22 PM, Yuri <yvoinov@xxxxxxxxx> wrote:

Show output of

ls -al /var/lib/ssl_db

12.09.2017 0:21, Rohit Sodhia пишет:

Yes, but telling me it's crashing unfortunately doesn't help me figure out why or how to fix it. I've run the command it suggests but it doesn't help. I'm unfortunately not an ops guy familiar with this kind of stuff; I don't see anything on how to figure out what to do about it.

On Mon, Sep 11, 2017 at 2:17 PM, Yuri <yvoinov@xxxxxxxxx> wrote:

It tells you what's happens.


11.09.2017 23:50, Rohit Sodhia пишет:

> (ssl_crtd): Uninitialized SSL certificate database directory:
> /var/lib/ssl_db. To initialize, run "ssl_crtd -c -s /var/lib/ssl_db".

_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users