- users - lists.freelock.com

technology write for us
by techpostinweb143＠gmail.com 19 Oct '21

19 Oct '21

One of the best guest blogging site with high quality content and domain authority. Write For US- Business, Tech News, Social media, Cloud Computing, Gadgets, Computers, Hardware, Apps / Reviews, SEO & Search Marketing and Operating Systems etc. We work hard to bring about best content that add value to them. https://www.techpostinweb.com/write-for-us/

1 0

Re: Problem moving from 1.7.35 to 1.8.13
by Louis 18 Oct '21

18 Oct '21

Ok, I found a couple issues with my process, which I believe are resolved. Now I generate both a roles backup and a db backup from the tarball instance and save them. I then add: CREATE DATABASE hethcote WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8'; ALTER DATABASE hethcote OWNER TO lbmoore; \connect hethcote to the beginning of the db.sqlc from the backup. (Without this the database gets added to postgres' default database postgres.) then I execute (via script): docker-compose pull docker-compose up -d docker exec -i ledgersmb-docker_postgres_1 psql -Upostgres -W --command='\l' docker exec -i ledgersmb-docker_postgres_1 psql -Upostgres -W --command='\du' docker cp ROLES ledgersmb-docker_postgres_1:/docker-entrypoint-initdb.d docker cp DB ledgersmb-docker_postgres_1:/docker-entrypoint-initdb.d docker exec -i ledgersmb-docker_postgres_1 psql -Upostgres -W --command="\i /docker-entrypoint-initdb.d/ROLES" docker exec -i ledgersmb-docker_postgres_1 psql -Upostgres -W --command="\i /docker-entrypoint-initdb.d/DB" 2>&1 | tee log docker exec -i ledgersmb-docker_postgres_1 psql -Upostgres -W --command='\l' docker exec -i ledgersmb-docker_postgres_1 psql -Upostgres -W --command='\du' Everything runs as expected. Then I connect to setup.pl and see the database "hethcote" and select it. Then I have it upgrade the db from 1.7.35 to 1.7.36. While it is doing the upgrade it fails with: Error! psql:./sql/modules/Roles.sql:193: ERROR: relation "exchangerate_type_id_seq" does not exist CONTEXT: SQL statement "GRANT ALL ON exchangerate_type_id_seq TO lsmb_hethcote__exchangerate_edit" PL/pgSQL function lsmb__grant_perms(text,text,text) line 6 at EXECUTE dbversion: hethcote, company: 1.7.36 Attempting to login via login.pl still fails with "Access denied: Bad username/password". Looking into the log from the database build it contains: ... COMMENT psql:/docker-entrypoint-initdb.d/db.sqlc:24821: ERROR: syntax error at or near "AS" LINE 2: AS integer ^ psql:/docker-entrypoint-initdb.d/db.sqlc:24824: ERROR: relation "public.exchangerate_type_id_seq" does not exist psql:/docker-entrypoint-initdb.d/db.sqlc:24830: ERROR: relation "public.exchangerate_type_id_seq" does not exist CREATE SEQUENCE ALTER TABLE ... the command that failed is: -- -- Name: exchangerate_type_id_seq; Type: SEQUENCE; Schema: public; Owner: postgres -- CREATE SEQUENCE public.exchangerate_type_id_seq AS integer START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; I am still stuck but have a better process for consistency in rebuilding the environment. Louis On Fri, 15 Oct 2021, lsmbdev wrote: > Hi Louis, > > Are you able to login to setup.pl with the pg admin user (normally postgres in the containers) with no company name? > > Once logged in like that you should see a list of databases present on the cluster. > > Regards > David Godfrey > > > > Sent from my Galaxy > > > -------- Original message -------- > From: Louis <lbmlist(a)hethcote.com> > Date: 15/10/21 02:11 (GMT+08:00) > To: lsmbdev <lsmbdev(a)sbts.com.au> > Cc: users(a)lists.ledgersmb.org > Subject: RE: [ledgersmb-users] Problem moving from 1.7.35 to 1.8.13 > > > > Ok, I've been trying various iterations of this without success. > > I have scripted it so that I can replicate with accuracy. Basically I > > 1) Log in to existing tarball instance with a known good username and > password > > 2) Log out of tarball instance and shutdown the tarball starman. > > 3) ensure all of previously existing docker instance is removed > > 4) use the docker-compose method of starting postges and lsmb > containers. > > 5) do a pg_dump of tarball instance "hethcote" database > > 6) create the same good username and password in the container's postgres > and check that the md5sum passwords match. > > 7) copy the pg_dump into the postgres container > > 8) docker exec psql with \i to load the pg_dump from tarball instance to > docker instance > > 9) log in using known good username from tarball instance into the docker > instance and get a bad username/password message. > > Is there something I missing? > > Louis > > > On Sat, 18 Sep 2021, lsmbdev wrote: > > > Hi Louis, > > > > If you have no objections to trying our docker containers I'd suggest doing a backup and, after > > installing docker-compose, restore to the containerised setup. > > > > > > Most development work, and many production instance are now using docker containers, so it's > > considered to be quite stable and easily supported. > > > > Regards > > David Godfrey > > > > > > Sent from my Galaxy > > > > > > -------- Original message -------- > > From: Louis <lbmlist(a)hethcote.com> > > Date: 18/9/21 23:43 (GMT+08:00) > > To: lsmbdev <lsmbdev(a)sbts.com.au> > > Cc: Louis <lbmlist(a)hethcote.com> > > Subject: RE: [ledgersmb-users] Problem moving from 1.7.35 to 1.8.13 > > > > > > This is installed from source. The database has been rolled along since > > SQLedger 2.x and migrated to LedgerSMB at the time of the fork. PostgreSQL > > itself is at v11 but has rolled along from v6 (don't recall orig version > > from the SQLedger days.) > > > > The hba file has always trusted local socket connections (pause for moment > > of shame) so password was blank until the 1.6 series. Since 1.6 password > > was just a random character since it was ignored. This is how 1.7.35 has > > been working. This is true for postgres as well as my own lbmoore. > > > > So decades of bad practices have finally caught up to me with 1.8. > > > > I'm at a loss as to where to start with this mess. > > > > Louis > > > > > > > > On Sat, 18 Sep 2021, lsmbdev wrote: > > > > > Morning Louis, > > > > > > The most common cause of this would be using the incorrect credentials with setup.pl > > > > > > Remember that the username is not a username you use to log into your company. > > > In many cases it is simply "postgres" > > > > > > Is your installation via a container, or did you install from source? > > > > > > Regards > > > David Godfrey > > > > > > Sent from my Galaxy > > > > > > > > > -------- Original message -------- > > > From: Louis <lbmlist(a)hethcote.com> > > > Date: 18/9/21 09:28 (GMT+08:00) > > > To: users(a)lists.ledgersmb.org > > > Subject: [ledgersmb-users] Problem moving from 1.7.35 to 1.8.13 > > > > > > > > > Hey all, > > > > > > I have not been able to move to the 1.8 series from the 1.7 series. I > > > think I must not have authentication correct and the 1.8 is expecting a > > > different setup than previous version. > > > > > > This is a starman installation. I will backup the DB, move the code into > > > place and run setup.pl. Setup pops open an error reading: > > > > > > Localhost:5762 says > > > > > > Access denied (500): bad username/password > > > > > > I'm using the same credentials as with 1.7.35. > > > > > > I can roll back and forth easily, but I don't see what the debug path > > > should be. > > > > > > Any help would be appreciated. > > > > > > Louis > > > > > > > > > _______________________________________________ > > > users mailing list -- users(a)lists.ledgersmb.org > > > To unsubscribe send an email to users-leave(a)lists.ledgersmb.org > > > > > > > > > > > >

3 3

Re: Problem moving from 1.7.35 to 1.8.13
by Louis 14 Oct '21

14 Oct '21

Ok, I've been trying various iterations of this without success. I have scripted it so that I can replicate with accuracy. Basically I 1) Log in to existing tarball instance with a known good username and password 2) Log out of tarball instance and shutdown the tarball starman. 3) ensure all of previously existing docker instance is removed 4) use the docker-compose method of starting postges and lsmb containers. 5) do a pg_dump of tarball instance "hethcote" database 6) create the same good username and password in the container's postgres and check that the md5sum passwords match. 7) copy the pg_dump into the postgres container 8) docker exec psql with \i to load the pg_dump from tarball instance to docker instance 9) log in using known good username from tarball instance into the docker instance and get a bad username/password message. Is there something I missing? Louis On Sat, 18 Sep 2021, lsmbdev wrote: > Hi Louis, > > If you have no objections to trying our docker containers I'd suggest doing a backup and, after > installing docker-compose, restore to the containerised setup. > > > Most development work, and many production instance are now using docker containers, so it's > considered to be quite stable and easily supported. > > Regards > David Godfrey > > > Sent from my Galaxy > > > -------- Original message -------- > From: Louis <lbmlist(a)hethcote.com> > Date: 18/9/21 23:43 (GMT+08:00) > To: lsmbdev <lsmbdev(a)sbts.com.au> > Cc: Louis <lbmlist(a)hethcote.com> > Subject: RE: [ledgersmb-users] Problem moving from 1.7.35 to 1.8.13 > > > This is installed from source. The database has been rolled along since > SQLedger 2.x and migrated to LedgerSMB at the time of the fork. PostgreSQL > itself is at v11 but has rolled along from v6 (don't recall orig version > from the SQLedger days.) > > The hba file has always trusted local socket connections (pause for moment > of shame) so password was blank until the 1.6 series. Since 1.6 password > was just a random character since it was ignored. This is how 1.7.35 has > been working. This is true for postgres as well as my own lbmoore. > > So decades of bad practices have finally caught up to me with 1.8. > > I'm at a loss as to where to start with this mess. > > Louis > > > > On Sat, 18 Sep 2021, lsmbdev wrote: > > > Morning Louis, > > > > The most common cause of this would be using the incorrect credentials with setup.pl > > > > Remember that the username is not a username you use to log into your company. > > In many cases it is simply "postgres" > > > > Is your installation via a container, or did you install from source? > > > > Regards > > David Godfrey > > > > Sent from my Galaxy > > > > > > -------- Original message -------- > > From: Louis <lbmlist(a)hethcote.com> > > Date: 18/9/21 09:28 (GMT+08:00) > > To: users(a)lists.ledgersmb.org > > Subject: [ledgersmb-users] Problem moving from 1.7.35 to 1.8.13 > > > > > > Hey all, > > > > I have not been able to move to the 1.8 series from the 1.7 series. I > > think I must not have authentication correct and the 1.8 is expecting a > > different setup than previous version. > > > > This is a starman installation. I will backup the DB, move the code into > > place and run setup.pl. Setup pops open an error reading: > > > > Localhost:5762 says > > > > Access denied (500): bad username/password > > > > I'm using the same credentials as with 1.7.35. > > > > I can roll back and forth easily, but I don't see what the debug path > > should be. > > > > Any help would be appreciated. > > > > Louis > > > > > > _______________________________________________ > > users mailing list -- users(a)lists.ledgersmb.org > > To unsubscribe send an email to users-leave(a)lists.ledgersmb.org > > > > > > >

2 1

13377x Proxy, Search Engine Torrentz Unblock Mirror Sites
by techpost1899＠gmail.com 14 Oct '21

14 Oct '21

Most users these days are less interested in subscription plans and looking for the torrent sites where the premium content is available for free of cost. If you are that type of user, then 13377x or 13377x.to is the best option to download movies, web series, software apps, or games, etc. https://www.techpostinweb.com/13377x-proxy/

1 0

13377x Proxy, Search Engine Torrentz Unblock Mirror Sites
by techpost1899＠gmail.com 14 Oct '21

14 Oct '21

Most users these days are less interested in subscription plans and looking for the torrent sites where the premium content is available for free of cost. If you are that type of user, then 13377x or 13377x.to is the best option to download movies, web series, software apps, or games, etc. https://www.techpostinweb.com/13377x-proxy/

1 0

13377x Proxy, Search Engine Torrentz Unblock Mirror Sites
by techpost1899＠gmail.com 14 Oct '21

14 Oct '21

Most users these days are less interested in subscription plans and looking for the torrent sites where the premium content is available for free of cost. If you are that type of user, then 13377x or 13377x.to is the best option to download movies, web series, software apps, or games, etc.

1 0

13377x Proxy, Search Engine Torrentz Unblock Mirror Sites
by techpost1899＠gmail.com 14 Oct '21

14 Oct '21

Most users these days are less interested in subscription plans and looking for the torrent sites where the premium content is available for free of cost. If you are that type of user, then 13377x or 13377x.to is the best option to download movies, web series, software apps, or games, etc.

1 0

Seo company tirupati
by honeyweb728＠gmail.com 14 Oct '21

14 Oct '21

seo company tirupati is a much-anticipated service to grow your business online. SEO companies like us assist in increasing the rank of the websites and portals too. We have formed advanced features in the field of SEO Service. with advanced features. These features allow search engines to bring customer’s websites to top results. Then, we are there to offer publicity to your websites with quality assurance. Also, we offer every kind of solution to highlight the website and have been serving our SEO service consistently for so many years. Hence, our team takes care of every need of the customer. https://www.honeywebsolutions.com/seo-company-tirupati/

1 0

LedgerSMB 1.9.2 released
by Erik Huelsmann 12 Oct '21

12 Oct '21

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.9.2 * Fix sending mail with multiple Bcc addresses (#6087) * Fix manual taxes on credit invoices (#5721) * Add missing account configuration on Sales account (#6100) * Fix Update clobbering invoice header data (e.g. fx rate) (#6114) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.9.2/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.9.2 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.9.2 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.9.2 These are the sha256 checksums of the uploaded files: 73a5006669cbb177c732602ecbf9f85c3b11d8171eeecebcc0cf933eca9f7c02 ledgersmb-1.9.2.tar.gz 50c09dd7652d6054189e82d5e1f37b4b1bca19467f7a14fc54a68ff80dcb7deb ledgersmb-1.9.2.tar.gz.asc

1 0

[SECURITY] Security advisory for CVE-2021-3882 (non-Secure session cookie)
by Erik Huelsmann 12 Oct '21

12 Oct '21

On September 16th, the LedgerSMB project was advised of a security vulnerability in the code. Please see below our security advisory. Sensitive Cookie in HTTPS Session Without 'Secure' Attribute Summary: ======== LedgerSMB does not set the 'Secure' attribute on the session authorization cookie when the client uses HTTPS and the LedgerSMB server is behind a reverse proxy. By tricking a user to use an unencrypted connection (HTTP), an attacker may be able to obtain the authentication data by capturing network traffic. Known vulnerable: ================= All of: - 1.8.0 upto 1.8.21 (including) Known fixed: ============ - 1.8.22 Details: ======== LedgerSMB 1.8 and newer switched from Basic authentication to using cookie authentication with encrypted cookies. Although an attacker can't access the information inside the cookie, nor the password of the user, possession of the cookie is enough to access the application as the user from which the cookie has been obtained. In order for the attacker to obtain the cookie, first of all the server must be configured to respond to unencrypted requests, the attacker must be suitably positioned to eavesdrop on the network traffic between the client and the server *and* the user must be tricked into using unencrypted HTTP traffic. Proper audit control and separation of duties limit Integrity impact of the attack vector. Severity: ========= CVSSv3.1 Base Score: 5.9 (Medium) CVSSv3.1 Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N Recommendations: ================ Users of LedgerSMB 1.8 are urged to upgrade to known-fixed versions. Users of LedgerSMB 1.7 or 1.9 are unaffected by this vulnerability and don't need to take action. As a workaround, users may configure their Apache or Nginx reverse proxy to add the Secure attribute at the network boundary instead of relying on LedgerSMB. For Apache, please refer to the 'Header always edit' configuration command in the mod_headers module. For Nginx, please refer to the 'proxy_cookie_flags' configuration command. References: =========== CVE-2021-3882 (LedgerSMB) https://ledgersmb.org/cve-2021-3882-sensitive-non-secure-cookie https://huntr.dev/bounties/7061d97a-98a5-495a-8ba0-3a4c66091e9d/ Reported by: ============ 0xdhinu, user of the huntr.dev platform Patches: ======== index 8dbcacddd..063e44415 100644 --- a/lib/LedgerSMB/Middleware/AuthenticateSession.pm +++ b/lib/LedgerSMB/Middleware/AuthenticateSession.pm @@ -209,7 +209,7 @@ sub call { $dbh->rollback; $dbh->disconnect; - my $secure = ($env->{SERVER_PROTOCOL} eq 'https') ? '; Secure' : ''; + my $secure = ($env->{HTTPS} eq 'ON') ? '; Secure' : ''; my $path = LedgerSMB::PSGI::Util::cookie_path($env->{SCRIPT_NAME}); return Plack::Util::response_cb( $res, sub { -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0