Test mail
This is a test mail for some new list functionality that accidentally got broken today. Apologies, and please ignore this mail. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: pgadmin-for-web is going nowhere
On Fri, Jul 14, 2017 at 7:58 PM, Devrim Gündüz wrote: > > Hi, > > On Fri, 2017-07-14 at 09:01 +0100, Dave Page wrote: > > > Right - your suggestion there was reverted because it became quickly > clear > > that it broke the default desktop mode. > > What if I invent an optional "pgadmin4-v1-web-setup" (or whatever) package, > that does what Josh suggested? > Shouldn't it be 3 packages? * pgadmin-core (pgadmin general codebase and dependent only on that) * pgadmin-desktop (the desktop app, depends on pgadmin-core and whatever qt packages are required) * pgadmin-web (the web app, depends on pgadmin-core and adds whatever other dependencies are necessray, drops a config file for webserver etc) or am I thinking wrong? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: pgadmin-for-web is going nowhere
On Fri, Jul 14, 2017 at 8:26 PM, Josh Berkus wrote: > On 07/14/2017 08:04 AM, Robert Eckhardt wrote: > > Josh, > > > > I'd be interested in knowing what specific things could be done to make > > you think that the Web version is no longer the 'ugly stepchild'. > > > > If I consider our (Pivotal's) current development process then the most > > honest thing we could say is that the desktop application is our > > afterthought. All of our development is done in the browser, our > > acceptance environment is an application pushed into a garden container > > hosted in the cloud. > > > > Admittedly, we haven't focused on the installation experience so if you > > could explain why it is so painful we could look at merging some of the > > things we are doing for acceptance into the application itself for > > distribution. > > Well, the immediate issues are addressed in two tickets: > > https://redmine.postgresql.org/issues/2496 > > https://redmine.postgresql.org/issues/2495 > > The summary of these is that, out of the box, the existing RPMs install > 200MB of extra software and don't result in a working install. > > There is another, major issue I didn't attempt to address, which is > offering a less-heavyweight webserver option than Apache HTTPD, mainly > for container-based deployment. I don't have a strong candidate for > this which is well-maintained upstream, though, because of the > single-process requirement. There's a bunch of simple-python > appservers, but none of them are well-packaged and maintained. > > I don't know how simple you consider uwsgi, but it's certainly well packaged and maintained in my experience. Now granted that experience is mostly on debian based platform so it might differ on redhat families, but it seems likely. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: [pgadmin4] unable to pull remote
Hi! Did that actually fix it? I've noticed a couple of other jobs complaining about the git server, but so far I was under the impression that it was a specific upstream network that had issues. BUt if switching to http fixed it, then that's not it, and I have something else to investigate. Also as a note -- it should be https and not http. If you use http it will generate redirects so it will work, but you both miss out on the security and will get lower performance because it will be more requests. //Magnus On Wed, Aug 9, 2017 at 11:30 AM, Sarah McAlear wrote: > Great, thank you! > > On Wed, Aug 9, 2017 at 5:26 PM, Harshal Dhumal < > harshal.dhu...@enterprisedb.com> wrote: > >> hi >> >> Change below url in your git config >> from *git://git.postgresql.org/git/pgadmin4.git >> <http://git.postgresql.org/git/pgadmin4.git>* to >> *http://git.postgresql.org/git/pgadmin4.git >> <http://git.postgresql.org/git/pgadmin4.git>* >> >> >> >> -- >> *Harshal Dhumal* >> *Sr. Software Engineer* >> >> EnterpriseDB India: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >> On Wed, Aug 9, 2017 at 2:39 PM, Sarah McAlear >> wrote: >> >>> Hi Hackers! >>> >>> We noticed that as of some time today (it worked this morning) we are >>> unable to pull git.postgresql.org/git/pgadmin4.git. Is this a known >>> issue? Our other repos seem to work fine still. >>> >>> Thanks, >>> Sarah >>> >> >> > -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: [pgadmin4] unable to pull remote
Hi! Thanks for confirming! I have now also found and fixed the git:// URL issue so anybody else still using those should be back to working. But there is no reason for you to switch back. //Magnus On Wed, Aug 9, 2017 at 12:37 PM, Sarah McAlear wrote: > Hi! > > Yes, this did fix it for us, but we did use https instead. > > Thanks! > Matt & Sarah > > On Wed, Aug 9, 2017 at 6:19 PM, Magnus Hagander > wrote: > >> Hi! >> >> Did that actually fix it? >> >> I've noticed a couple of other jobs complaining about the git server, but >> so far I was under the impression that it was a specific upstream network >> that had issues. BUt if switching to http fixed it, then that's not it, and >> I have something else to investigate. >> >> Also as a note -- it should be https and not http. If you use http it >> will generate redirects so it will work, but you both miss out on the >> security and will get lower performance because it will be more requests. >> >> //Magnus >> >> >> On Wed, Aug 9, 2017 at 11:30 AM, Sarah McAlear >> wrote: >> >>> Great, thank you! >>> >>> On Wed, Aug 9, 2017 at 5:26 PM, Harshal Dhumal < >>> harshal.dhu...@enterprisedb.com> wrote: >>> >>>> hi >>>> >>>> Change below url in your git config >>>> from *git://git.postgresql.org/git/pgadmin4.git >>>> <http://git.postgresql.org/git/pgadmin4.git>* to >>>> *http://git.postgresql.org/git/pgadmin4.git >>>> <http://git.postgresql.org/git/pgadmin4.git>* >>>> >>>> >>>> >>>> -- >>>> *Harshal Dhumal* >>>> *Sr. Software Engineer* >>>> >>>> EnterpriseDB India: http://www.enterprisedb.com >>>> The Enterprise PostgreSQL Company >>>> >>>> On Wed, Aug 9, 2017 at 2:39 PM, Sarah McAlear >>>> wrote: >>>> >>>>> Hi Hackers! >>>>> >>>>> We noticed that as of some time today (it worked this morning) we are >>>>> unable to pull git.postgresql.org/git/pgadmin4.git. Is this a known >>>>> issue? Our other repos seem to work fine still. >>>>> >>>>> Thanks, >>>>> Sarah >>>>> >>>> >>>> >>> >> >> >> -- >> Magnus Hagander >> Me: https://www.hagander.net/ <http://www.hagander.net/> >> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/> >> > > -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: [pgaweb][patch] Use https link for git repo
On Tue, Aug 29, 2017 at 4:45 PM, Dave Page wrote: > > > On Tue, Aug 29, 2017 at 3:30 PM, Matthew Kleiman > wrote: > >> bump. >> >> On Tue, Aug 15, 2017 at 3:58 AM Matthew Kleiman >> wrote: >> >>> Hi Hackers, >>> >>> As per discussion on https://www.postgresql.org/ >>> message-id/flat/CAGRPzo-_dSYr5Y1D%2B0uBLo39Bb6MVTg3%3DCM% >>> 3DhrmX7LdF%3DfQbhQ%40mail.gmail.com#CAGRPzo-_dSYr5Y1D+ >>> 0uBLo39Bb6MVTg3=CM=hrmX7LdF=fq...@mail.gmail.com, I've updated the >>> pgadmin website with the attached patch. Instead of the docs pointing >>> developers to an ssh repo link, it points them to https. >>> >>> > Hi > > I prefer to keep it as git:// - I've seen caching weirdness with http(s) > in the past. > Those weirdnesses *should* all be gone if it uses the smart http mode, which we didn't support until a few weeks ago, but do now. > git:// is supported, and per the thread, Magnus did fix the issue seen. Is > there any other reason to change it? > > Security? In particular, MITM:ing initial connections etc. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
pgadmin4 container docs bug
Looks like a simple copy/paste bug. //Magnus diff --git a/pkg/docker/README b/pkg/docker/README index ba04dfa8..7d4ea890 100644 --- a/pkg/docker/README +++ b/pkg/docker/README @@ -38,7 +38,7 @@ This is the password used when setting up the initial administrator account to l PGADMIN_ENABLE_TLS -- -Default: Conta1ner +Default: False If set to the default, False, the container will listen on port 80 for connections in plain text. If set to True, the container will listen on port 443 for TLS connections.
Re: Showstopper desktop runtime issue
m and a bunch of different solutions to try to > handle it, or even advises on how to handle it. This option also allow us > to focus less on browser compatibility as the main target of our > development will become Chromium which is the base of browsers like UC > Browser, Vivaldi, Opera, Google Chrome. > Please don't ever give up browser independence for the *web* version of pgadmin. Don't be That Project (TM). (And don't give up on proper tabs either, but I'm sure Electron might catch up in that eventually -- and the issue around RHEL6 will also go away eventually) -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Showstopper desktop runtime issue
On Thu, Mar 22, 2018 at 5:28 PM, Dave Page wrote: > >> >> 3) Electron >>> >>> Pros: >>> - Full Javascript runtime, no more C++ code to handle >>> - Self packaging for all the environments >>> Cons: >>> - No fully supported on Linux based OS with old libstdc++, (This might >>> solve the problem: https://github.com/mattermost/desktop/issues/312) >>> >> >> >> Losing support for things like RHEL6 would make it completely unworkable >> for several of my largest customers. Particularly in large enterprise >> organisations, this would be a very substantial issue. >> > > That's good to know. There are clunky workarounds (shipping different > libcs for example, but that potentially adds licensing issues). > > Sidenote: It would only be an issue for desktop mode. Web mode should not > be affected. > Right. > - CPU/RAM high utilization (Found a issues around and the majority of them >>> have solutions like CSS animations running or settings on the created >>> windows) >>> >> >> This does sound bad. But do we actually know if this is worse in Electron >> than it is in the option #2? I mean sure, we point to things like Slack, >> but that may not be because of electron, it may be because the app running >> inside it? >> > > We don't know for sure, but we do know that Chrome in general is a bit of > a hog. It's certainly not a stretch to think a combination of those things > are why people (correctly) see browser based apps as being more resource > hungry. > It is, but is it more of a hog than other modern browsers? :) (I mean, every single Electron app I've ever used has been absolutely horrible from a CPU/RAM/Battery utilization, to the point that I've deleted them all, but blame needs to be assigned to the right place) > - Electron does not support tabs by default, only HTML tabs >>> >> >> I think that also makes it a showstopper. This was another one of the >> main complaints I have personally heard from people going from pgadmin3 -> >> pgadmin4, and enough to make people not want to use it at all. It would be >> really bad to go back to that. >> > > To clarify; it would mean no tabs, but not single window. That was already > working in the PoC. In other words, helpfiles, the debugger and query tools > could all be opened in new windows, just not tabs on the same window that > could be docked and un-docked. > > I suspect for most people that would be enough. > What people want, in my experience, is it for different queries. Haven't really seen requests for it when it comes to anything other than that. But people do definitely want the ability to do those both in tabs and in windows, by their choice, if at all possible. 3) Electron can to play, first when we though about removing QTWebkit, >>> because it always packs a browser with it and also and there is a very big >>> Open Source Community being it. It came back again when when we saw that we >>> were ready to ditch the browser. (As a personal note I dislike applications >>> that I install in my machine and pop browser open to do anything, this is a >>> personal issue that I would like to see if it was shared by others that was >>> why we decided to park Electron for a second time. Because if our users are >>> ok with it there is no need to add extra complexity to the product) >>> The most interesting thing about the cons that I found in Electron there >>> is an issue open for them and a bunch of different solutions to try to >>> handle it, or even advises on how to handle it. This option also allow us >>> to focus less on browser compatibility as the main target of our >>> development will become Chromium which is the base of browsers like UC >>> Browser, Vivaldi, Opera, Google Chrome. >>> >> >> Please don't ever give up browser independence for the *web* version of >> pgadmin. Don't be That Project (TM). >> > > Not on my watch! > :) (And don't give up on proper tabs either, but I'm sure Electron might catch >> up in that eventually -- and the issue around RHEL6 will also go away >> eventually) >> > > RHEL 6 is in support until 2024, though it's already halfway through the > maintenance 2 phase. It's definitely going, but we really don't know how > many folks might still be using it in production on systems they're > updating and using pgAdmin on. That last bit is important; many folks will > continue to run production servers on RHEL/CentOS 6 for years, but how many > are usin
Re: Showstopper desktop runtime issue
On Thu, Mar 22, 2018 at 5:38 PM, Robert Eckhardt wrote: > > > On Thu, Mar 22, 2018 at 12:28 PM, Dave Page wrote: > >> >>> (And don't give up on proper tabs either, but I'm sure Electron might >>> catch up in that eventually -- and the issue around RHEL6 will also go away >>> eventually) >>> >> >> RHEL 6 is in support until 2024, though it's already halfway through the >> maintenance 2 phase. It's definitely going, but we really don't know how >> many folks might still be using it in production on systems they're >> updating and using pgAdmin on. That last bit is important; many folks will >> continue to run production servers on RHEL/CentOS 6 for years, but how many >> are using them for client-side stuff or actively updating things like >> pgAdmin on them? >> > > RHEL 6 is the #1 OS for GPDB so if we have customers installing server > side or wanting to we'd be on this pretty quickly. > > As an aside, I'm interested in who and how people are using the Linux > version. How many are using Linux on the desktop and how many are > installing the server. My assumption is that people using the linux distro > are installing the server but I have no actual information to base that on. > My experience is actually the opposite in a lot of cases. The server pgadmin is used primarily by those of my customers who are using Windows -- mainly as a workaround for the fact that the performance experience of the desktop app on Windows was horrible. On Mac I don't think I've seen anybody choose the server version if it's a primary tool for them (some still have a shared pgadmin for people who only touch it at very infrequent cases, but it's not common). On Linux, I see a mix. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Re: Move pgAdmin git repo to Github?
On Thu, May 21, 2020 at 1:08 PM Dave Page wrote: > We see a non-trivial amount of automated build failures caused by git > timeouts and Varnish cache meditation. This is only likely to get worse as > we've automated so many different build configurations, and the PostgreSQL > sysadmin team don't really want to get into the business of large-scale > repository hosting. > > I suggest we move our primary repo to Github. Any objections? > > Don't you already have a mirror there? Can't you just point the tests at that, regardless of where you keep your primary? (It is distributed after all) That said you are of course free to change the primary for whatever reason, but this one doesn't seem like one. And AFAIK nobody has actually reported any such issues. But it is certainly true that a lot of the git serving stuff is terribly slow -- but I was under the impression that it was mostly gitweb, since thats what people tend to report issues with... But again, no actual objections to moving. //Magnus
Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1
On Sun, Jan 3, 2021 at 6:31 PM Stephen Frost wrote: > > Greetings, > > * Dave Page (dp...@pgadmin.org) wrote: > > On Sat, 2 Jan 2021 at 15:59, Stephen Frost wrote: > > > * Dave Page (dp...@pgadmin.org) wrote: > > > > On Sat, 2 Jan 2021 at 15:41, Stephen Frost wrote: > > > > > * Khushboo Vashi (khushboo.va...@enterprisedb.com) wrote: > > > > > > Please find the attached patch to support Kerberos Authentication in > > > > > > pgAdmin RM 5457. > > > > > > > > > > > > The patch introduces a new pluggable option for Kerberos > > > authentication, > > > > > > using SPNEGO to forward kerberos tickets through a browser which > > > > > > will > > > > > > bypass the login page entirely if the Kerberos Authentication > > > succeeds. > > > > > > > > > > I've taken a (very short) look at this as it's certainly something > > > > > that > > > > > I'm interested in and glad to see work is being done on it. > > > > > > > > > > I notice that 'delegated_creds' is being set but it's unclear to me > > > > > how > > > > > they're actually being used (if at all), which is a very important > > > > > part > > > > > of Kerberos. > > > > > > > > > > What's commonly done with mod_auth_kerb/mod_auth_gss is that the > > > > > delegated credentials are stored on the filesystem in a temporary > > > > > directory and then an environment variable is set to signal to libpq / > > > > > the Kerberos libraries that the delegated credentials can be found in > > > > > the temporary file. I don't see any of that happening in this patch- > > > is > > > > > that already handled in some way? If not, what's the plan for making > > > > > that work? Also important is to make sure that this approach will > > > > > work > > > > > for constrainted delegation implementations. > > > > > > > > Phase 1 of this project (which this patch aims to implement) is to > > > > handle > > > > Kerberos logins to pgAdmin when running in server mode (as we’ve already > > > > done for LDAP, except KRB authenticated users don’t see a login page of > > > > course). Phase 2 will add support for logging into the PostgreSQL > > > servers - > > > > I believe that is where we’ll need to handle delegated credentials, > > > correct? > > > > > > Yes, though I sure hope there isn't a plan to release just 'phase 1' > > > since that would imply that the user is still sending their password to > > > pgAdmin in some form that pgAdmin then turns around and impersonates the > > > user, basically completely against how Kerberos auth should be working > > > in this kind of a intermediate service arrangement. > > > > > > In other words, if just 'phase 1' is released, it'd probably be CVE > > > worthy right out of the gate... > > > > It wouldn’t impersonate the user at all, it would just work as it does now, > > requiring the user to supply a username/password for scram/md5/ldap etc, or > > a cert for SSL auth. Connection to a PostgreSQL server which required gss > > or sspi simply wouldn’t work (unless the service account under which the > > pgAdmin server is running has a valid ticket through other means). > > That *is* impersonating the user.. > > Kerberized services really should *not* be accepting a cleartext > password to use to authenticate as the user against another service, > which is why I'd strongly recommend against releasing with just > 'phase 1' done.. or at least heavily caveat'ing it that this isn't > actually real Kerberos support but is just an intermediate step that no > one should really deploy... AIUI that's not what's being proposed. Correct me if I'm wrong, but I think what's said is that this phase would: 1. Allow kerberos login *to pgadmin*. 2. Do exactly *nothing* to logins to the database server. So per (2) logins to the db server would work exactly the same as it does today, and bear no connection to the actual KRB login at all. One question around that though -- when I click "save password" on a database connection in pgadmin, it gets stored on the pgadmin server. Isn't the key used to encrypt that derived from my password? If I'm logging into pgadmin without a password (using kerberos),what would that key be derived from? -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Somewhat excessive version checks
Hi! If I read the code correctly, pgadmin will (unless turned off) hit the website to check the version.json file for updates *every time it starts*. Wouldn't it make sense to rate limit that to checking say once per 24 hours maximum? Or even 48? It seems nobody needs the update *that* quickly, and AFAICT it does call out to make that check synchronously on startup which means the user is waiting. And if/when doing that, it would be useful to include an If-Modified-Since header on the request, so the server can just respond with a tiny 304 reply when there is no update, which is going to be the majority of the time. Or possibly even more efficiently, create a custom etag and use If-None-Matches. If you make that etag be say the version that the client has, it becomes very cheap to check and you don't need to track any extra data. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1
t that part done. All I'm saying is that the >> 'phase 1' part really shouldn't be independently released, or if it is, >> it should be *heavily* caveated that it is strongly discouraged for >> people to run it in an environment where pgadmin and PG are in the same >> Kerberized environment because it's not possible to set that up, with >> just phase 1 done, in a manner which would avoid the pgadmin and PG >> servers seeing the user's password. > > > Phase 2 is scheduled to be done immediately. \o/ -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Somewhat excessive version checks
On Tue, Jan 12, 2021 at 9:57 AM Dave Page wrote: > > On Mon, Jan 11, 2021 at 10:06 PM Magnus Hagander wrote: >> >> Hi! >> >> If I read the code correctly, pgadmin will (unless turned off) hit the >> website to check the version.json file for updates *every time it >> starts*. > > > Every time the server starts, which is a little different, but still... Hmm. So one of us is definitely reading things wrong then :) I see it in the index() method, which has an URL router for / -- isn't that called for every time somebody somebody starts their browser to it? I'm not saying for every reload, but with a server install with 10 users, won't it do it once for each? Or when is that actually called? >> Wouldn't it make sense to rate limit that to checking say once per 24 >> hours maximum? Or even 48? > > > That certainly wouldn't be a bad idea. > >> >> >> It seems nobody needs the update *that* quickly, and AFAICT it does >> call out to make that check synchronously on startup which means the >> user is waiting. >> >> And if/when doing that, it would be useful to include an >> If-Modified-Since header on the request, so the server can just >> respond with a tiny 304 reply when there is no update, which is going >> to be the majority of the time. Or possibly even more efficiently, >> create a custom etag and use If-None-Matches. If you make that etag be >> say the version that the client has, it becomes very cheap to check >> and you don't need to track any extra data. > > > Patches welcome! Hah, I clearly can't even figure out when the method is called :) And presumably you'd also want some place to store the state between calls, so you can keep showing the warnings about upgrades? Do you have state storage for such things arleady= -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Somewhat excessive version checks
On Tue, Jan 12, 2021 at 5:59 AM Khushboo Vashi wrote: > > > > On Tue, Jan 12, 2021 at 3:36 AM Magnus Hagander wrote: >> >> Hi! >> >> If I read the code correctly, pgadmin will (unless turned off) hit the >> website to check the version.json file for updates *every time it >> starts*. >> >> Wouldn't it make sense to rate limit that to checking say once per 24 >> hours maximum? Or even 48? >> >> It seems nobody needs the update *that* quickly, and AFAICT it does >> call out to make that check synchronously on startup which means the >> user is waiting. >> > Agreed, we should have some mechanism in place to limit the server hit, maybe > an asynchronous call from the client while loading. Seems async front he server would be a better choice there, if you have some ways for that? Otherwise, how to determine which user to trust when storing the result etc? -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
