How to Build Postgres in a Portable / Relocatable fashion?
Back in the good old days there was official 1st-party support for Linux: https://www.enterprisedb.com/downloads/postgres-postgresql-downloads Those binaries could be tar xvf'd and used without any fuss or muss, from any location, on any distro. I'm the core maintainer of https://webinstall.dev/ and I'm thinking to break our "official builds only" rule because, well, I haven't been able to find any way to get up-to-date builds from an official channel - and apt is always half-a-decade out-of-date (part of the reason for Webi, but Webi is far worse in this case, stuck at v10). Could I get some help on how to do that? Are the old build processes documented somewhere? Or are there some scripts in a far corner of the Internet that could still do that? Or what options might I need to pass to ./configure to get it to build with relative locations? I'm not a C developer, and I'm not familiar with C build tools beyond ./configure; make; sudo make install. I'd really appreciate some direction on this. Thanks. AJ ONeal
Re: How to Build Postgres in a Portable / Relocatable fashion?
> > Back in the good old days there was official 1st-party support for Linux: > This > was/is a third party site. Oh. I thought that EDB was *the* Postgres company like MySQL AB was *the* MySQL company. My mistake. > and `apt` is always half-a-decade out-of-date I misspoke. I meant the OS repos more than apt itself. > As to Apt build scripts: I was just using apt as an example. I don't actually want to deal with apt or .debs. What I want to create (and provide) is a portable tarball that has most of all what it needs in the tarball and will look for relevant libraries relative to itself. Something that Just Works™ *almost* anywhere (Ubuntu, Debian, RedHat, Suse... maybe even Alpine). Any idea how to do that?
Re: How to Build Postgres in a Portable / Relocatable fashion?
> > What I want to create (and provide) is a portable tarball that has > > most of all what it needs in the tarball and will look for relevant > > libraries relative to itself. > > > See > > https://www.postgresql.org/docs/current/installation.html > > particularly the discussion of installation relocatability under > > https://www.postgresql.org/docs/current/install-make.html#CONFIGURE-OPTIONS-LOCATIONS It seems like the first bit of magic I need is: `--prefix=/doesntexist/postgres` Including 'postgres' as part of the name puts it in "relative mode", so-to-speak. Thank you! > > Something that Just Works™ almost anywhere (Ubuntu, Debian, RedHat, Suse... > > maybe even Alpine). > > > That's a little harder, mainly because the shared libraries for > dependencies like openssl etc may not be 100% compatible across > all those platforms. Different versions, different build options, > yadda yadda. I'd like to build as much static as possible (or reasonable). Is there a way to tell it "just include openssl"? > Maybe you should be thinking in terms of a docker container > or the like? I really hate Docker. The idea of "we can't ship your computer to the client, so we'll just ship... a clone of you computer to the client" offends my sensibilities. Or rather, I like the opportunity that LXC provides in the right context, but I don't like how it's become a replacement for shared knowledge within a group - i.e. "no one can remember the wisdom of the ancients, so if this fragile system that Ted built ever fails or needs a change no one knows how he did it or what the options mean, but don't worry, it's all encapsulated in a very complex Dockerfile that no one understands and depends on hundreds of layers of images... but it's not like someone would ever leftpad any of them... What could go wrong?"
Feature Request: Option for TLS no SSLRequest with psql
Could we get a `postgrestls://` or `sslmode=tls` or --tls option that instructs psql to sends straight TLS, skipping the 000804d2162f / 000804d21630 + N / Y / S handshake? Rationale: In the age of TLS, SNI, and ALPN, protocol routing and virtual hosting is easier, more reliable, and less expensive than it's ever been, but having to deal with a bespoke protocol handshake at "the edge" really puts a damper on things: Currently, every single proxy / TLS tool has to decide whether or not to support Postgres specifically. It's a lot of duplicate work and causes Postgres support to lag until someone who is 1) familiar with the language 2) familiar with the codebase 3) familiar with postgres' SSLRequest 4) and has power to review and accept changes is available (and willing) to help. (re: https://github.com/mholt/caddy-l4/issues/187, https://github.com/traefik/traefik/issues/9929, https://github.com/envoyproxy/envoy/issues/2861, https://github.com/therootcompany/sclient/issues/5, and many more) It would be great if the postgres server also supported receiving straight TLS, but since the reverse proxy / load balancer typically terminates the TLS in these settings, even if it were only available in the client, it would simplify protocol routing greatly. Note: in many instances subdomains are used to specify user/db to route to, so SNI+ALPN alone are enough to complete the routing, but even if the plaintext user/db/app message is being matched on, it's much easier for someone to write a module in any given proxy for that because it fits the same pattern as HTTP Host matching - it doesn't require a handshake on either side of the TLS termination, which is where the complexity comes in. AJ ONeal
Feature Request: Add "pg" as TLS-ALPN
In the same place that SNI is being passed to openssl during the client-initiated TLS, could we get ALPN set to "pg" by default (and perhaps an --alpn and/or --no-alpn) to assist in protocol routing / virtual hosting? P.S. I'm willing to personally fund the development of these two features I've requested. It would come out of my own pocket (no investors or enterprise behind me) - but I do a variety of development for a variety of clients and I believe that these changes will indirectly end up putting enough money back in my own pocket to make it worth it over the years. I could contract a member of the core team or, if we got to a sure-fire "will accept given these conditions", I could find someone in my friend or work group to commission to make the changes. AJ ONeal
