On 18/02/2016 6:43 a.m., Alex Rousskov wrote: > On 02/17/2016 10:29 AM, Amos Jeffries wrote: >> On 18/02/2016 5:59 a.m., William Lima wrote: >>>> the other uses Redis for certificate caches. > >>> A polished version of this would be a very welcomed addition for busy >>> bumping proxies IMO! >>> >>> AFAICT, this polishing would require generalizing Ssl::CertificateDb >>> into a base class providing open/get/put/close API to ssl_crtd and >>> containing any code common to the supported db flavors. Two >>> Ssl::CertificateDb kids would then cover the two known flavors: >>> >>> * OpenSslDb: The current clunky on-disk OpenSSL cache (available if >>> ssl_crtd was built with OpenSSL headers/library); >>> >>> * RedisDb: A shiny Redis database client (available if ssl_crtd was >>> built with Redis headers/library). >>> >>> The selection between the two kids will be determined, in part, by a >>> command line option. > > > >> FYI: the model we have for helpers is that each backend type is >> represented by a different helper binary that end-users configure to be >> used (or not). > > It is not clear where a helper configuration ends and "backend type" > begin. IMHO, it is better to have > > * a single helper that may be configured to use one of the two caching > modes (with reasonable defaults making that customization optional!) than > > * two helpers, each supporting only one caching mode (requiring the > admin to always explicitly pick the right helper!). > > >> The OpenSSL local filesystem one is now called "security_file_certgen". >> A Redis DB helper would be "security_redis_certgen". > > Why create a whole new binary? >
Because the "file" in its name means the data is stored to the local filesystem in some "flat-file" DB format. My understanding is that redis uses its own binary DB format. The redis version requires a whole new library linkage, its header files and code for its API use. As a result the two binaries will act very differently when passed the same data. Depending solely on which backend was chosen. With a lot of policy and security implications around those differences. For the squid.conf viewpoint the difference is trivial. But for the maintenance, support, security, and distributor activities it makes a lot of things easier to deal with two binaries. > >> Being able to build or omit helpers based on what the final environment >> contains is important for our redistributors and portability. > > This is not about building or omitting a helper AFAICT. It is about what > the helper does. Why not control that via a command line option, with > good defaults (among other things such as ./configure tests)? It is. A generic distro builder who builds two helpers leaves the installers with the option to actually install only one binary if the other does not meet local policy/security requirements. In the generic builders this is best supported by providing different packages with different binaries inside. Which gets very annoying and/or tricky if the difference is ./configure parameters (--with/--without-hiredis) to produce different buinaries. Its also about explaining to users why this "file" helper does not necessarily store things to the local FS, where all the others do. Amos _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
