[BlueOnyx:23086] Re: fixproftpd_conf.pl
Hi Ken, > I see this script in /usr/Sausalito/sbin and it seems to do what is says > in the comments: > > # $Id: fixproftpd_conf.pl Sat 25 Jan 2014 15:40:02 PM COT mstauber $ This script is deprecated. Once upon a time we used it after ProFTPd upgrades to add the -containers to proftpd.conf. But we eventually stopped using the -containers altogether, as they were more trouble than it was worth. -- With best regards Michael Stauber ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23085] fixproftpd_conf.pl
I see this script in /usr/Sausalito/sbin and it seems to do what is says in the comments: #!/usr/bin/perl -I/usr/sausalito/perl -I/usr/sausalito/handlers/base/vsite # $Id: fixproftpd_conf.pl Sat 25 Jan 2014 15:40:02 PM COT mstauber $ # # This script prints out the VirtualHost containers that are supposed to # be present in your /etc/proftpd.conf - based on the IPs your sites are # using. It seems to just print the missing VirtualHost containers, not insert them into proftpd.conf. Are these indeed still supposed to be present? Will running this script fix the problem my one customer is having? What about running the script and then pasting the output into proftpd.conf? Or was this script supposed to be called by some other script that would modify the conf file? ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23084] Re: "Easy Migrate" released \o/
Hi Tobias, > $ssh = Net::OpenSSH->new($host, timeout => 10); After some more testing it seems like the documentation of Net::OpenSSH was a bit off there. This is indeed a hard timeout that kicks in if STDIN falls silent. Which it sure will do when running a massive SQL-dump. I just bumped that timeout to 3 and published another update of easy-migrate. -- With best regards Michael Stauber ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23083] Re: "Easy Migrate" released \o/
Hi Tobias, > Are you going to start a SSH session from the source system on? No. The only SSH connections (and there are plenty of them during the migration) originate on the target server and end at the source server. > Then it might be worth to mention that both systems are working > on non standard ssh ports. In general that should not be a problem, as you can specify the SSH port on the command line and Easy-Migrate honors that throughout the migration. Just one more thing: Look at easy-migrate.pl and find this line: $ssh = Net::OpenSSH->new($host, timeout => 10); That should be in line 265. Change the timeout value of 10 to 1000 and see if that makes a difference. This timeout is not that straightforward, so this doesn't mean 10 seconds of inactivity of the launched process, but deals with keep alives and other things. It's a long shot, but worth a try. The other thing is: If SSH is run on a non-standard port and you have a firewall in between, then you often get a much shoddier SSH connection, as most firewalls know port 22 and if open prioritize SSH traffic over anything else. So just for testing purpose it might be worth it to drop SSH back to port 22 on the source server of the migration and see if that makes any difference. > The database export on the source system itself takes some time: one > of the databases is of 6.7 gig exported size - that's the reason of > the more than 2 minutes time the first step of the export takes. This could be. In that case the --nomysql switch might perhaps be useful and then migrate the MySQL databases afterwards. -- With best regards Michael Stauber ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23082] Re: CushyCMS and ProFTPD
This is probably a question for Michael. I see on the server files that seem to be saved copies of the old proftpd.conf, prior to yum updates: -rw--- 1 root root 6155 Nov 16 2014 proftpd.conf.pre-1.3.5 -rw--- 1 root root 11618 Jul 24 06:00 proftpd.conf.pre-1.3.5e The first one from 2014 does not have any of the entries that Tobias mentions. But the second one from a couple weeks ago has a bunch of entries like this: DefaultRoot / wheel DefaultRoot / admin-users DefaultRoot ~/../../.. site-adm DefaultRoot ~ !site-adm AllowOverwrite on DefaultChdir/web DisplayLogin.ftphelp DefaultRoot / wheel DefaultRoot / admin-users DefaultRoot ~/../../.. site-adm DefaultRoot ~ !site-adm AllowOverwrite on DefaultChdir/web DisplayLogin.ftphelp Currently my proftpd.conf has no VirtualHost containers at all. It looks like they appeared in 2014, and went away again in 2019. I had RaQ, RaQ3, RaQ550, BlueQuartz and now BlueOnyx. Through those 20 years, I always thought ftp users would have to cd to the /web directory. I think for a brief period I modified the DefaultRoot so siteadmins would start out in the site web directory rather than their home directory, but stopped that, I think because it would get blown away after updates. So did something change in 2014? I'm not sure if it was DefaultChdir as mentioned by Tobias, or DefaultRoot, or both? And did this get broken in the recent update? Or is it just my server? If those VirtualHost entries are supposed to be there, is there a script I can run to get them back? -Original Message- From: Blueonyx On Behalf Of Tobias Gablunsky Sent: Friday, August 2, 2019 9:41 AM To: BlueOnyx General Mailing List Subject: [BlueOnyx:23078] Re: CushyCMS and ProFTPD Hi Ken, have you checked if the entra "DefaultChdir/web" is still included in your /etc/proftpd.conf (resp. /etc/proftpds.conf)? This is the entry needed for changing directory to /web by default. Maybe this has changed through the update of proftpd? Regards, Tobias > -Original Message- > From: Blueonyx [mailto:blueonyx-boun...@mail.blueonyx.it] On Behalf Of > Ken Hohhof > Sent: Friday, August 02, 2019 2:48 PM > To: 'BlueOnyx General Mailing List' > Subject: [BlueOnyx:23076] Re: CushyCMS and ProFTPD > > It sounds like there was a genuine vulnerability that was fixed, so > I'm reluctant to roll back the update in order to accommodate one customer. > > Yesterday I signed up for a free Cushy account so I could reproduce > and troubleshoot the problem. To my surprise ... no problem! > > Here's my best guess, I think the customer's web designer who set up > the CMS probably used / as the path, while I used /web. And perhaps > this was causing Cushy to explore directories not owned by the > siteadmin, like maybe php.d. > > That still leaves the mystery of what changed in ProFTPd, because this > was working since 2016. But I'm hoping the customer does not have the > path set to /web, and that changing it will resolve the problem for > her. (Note that I suspect the web designer has a branded pro account > from Cushy and the customer is just enrolled as an editor of her site > and therefore can't see or change the configuration.) > > Web designers can be difficult to deal with. They are artists! And > hosting is just a commodity, low skill work by vendor scum who can be > replaced with the snap of a finger. > > -Original Message- > From: Blueonyx On Behalf Of > Michael Stauber > Sent: Thursday, August 1, 2019 1:09 PM > To: blueonyx@mail.blueonyx.it > Subject: [BlueOnyx:23063] Re: CushyCMS and ProFTPD > > Hi Ken, > > > Since the problem started with the ProFTPd bugfix, I'm starting to > > wonder if CushyCMS uses the site cpfr and site cpto commands. That > > seems unlikely, but I can't know for sure without signing up for a > > CushyCMS account myself to try it. The only other explanation I can > > think of is that the bugfix had some unanticipated consequences or > collateral damage. > > Yeah, it sure is related to the update. The ProFTPd we're using now is > a "release candidate" and I also observed that it does a few things > slightly different than the last stable version that we were using. > The code maturity seems to have dropped a notch or two. > > I don't have any other or better solution at the moment, sorry. But > perhaps you might temporarily go back to the last ProFTPd version that > worked for you? > > If so, please do this: > > rpm -e --nodeps proftpd > rm /etc/proftpd.conf > rm /etc/proftpds.conf > > That removes ProFTPd. Then you can grab the last good one. As I
[BlueOnyx:23081] Re: Gmail problems... again
Hi Lewis, > When I brought this issue up before the solution was to run the > following two commands: > >> sysctl -w net.ipv6.conf.all.disable_ipv6=1 >> sysctl -w net.ipv6.conf.default.disable_ipv6=1 > > However that does not seem to have the same joyful effect. Yeah, the above actually should work, but these settings won't survive a reboot. "sysctl -w" just performs a modification of kernel settings at runtime. Here is how you can make it more permanent and they outline several methods like sysctl config file or kernel boot parameter to disable IPv6 permanently: https://www.thegeekdiary.com/centos-rhel-7-how-to-disable-ipv6/ https://linuxhint.com/disable_ipv6_centos7/ -- With best regards Michael Stauber ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23080] Re: CushyCMS and ProFTPD
No, not there. Is this supposed to be a global directive, or per virtual host? Actually there are no virtual host containers in /etc/proftpd.conf. Should there be? BlueOnyx version is 5208R. -Original Message- From: Blueonyx On Behalf Of Tobias Gablunsky Sent: Friday, August 2, 2019 9:41 AM To: BlueOnyx General Mailing List Subject: [BlueOnyx:23078] Re: CushyCMS and ProFTPD Hi Ken, have you checked if the entra "DefaultChdir/web" is still included in your /etc/proftpd.conf (resp. /etc/proftpds.conf)? This is the entry needed for changing directory to /web by default. Maybe this has changed through the update of proftpd? Regards, Tobias > -Original Message- > From: Blueonyx [mailto:blueonyx-boun...@mail.blueonyx.it] On Behalf Of > Ken Hohhof > Sent: Friday, August 02, 2019 2:48 PM > To: 'BlueOnyx General Mailing List' > Subject: [BlueOnyx:23076] Re: CushyCMS and ProFTPD > > It sounds like there was a genuine vulnerability that was fixed, so > I'm reluctant to roll back the update in order to accommodate one customer. > > Yesterday I signed up for a free Cushy account so I could reproduce > and troubleshoot the problem. To my surprise ... no problem! > > Here's my best guess, I think the customer's web designer who set up > the CMS probably used / as the path, while I used /web. And perhaps > this was causing Cushy to explore directories not owned by the > siteadmin, like maybe php.d. > > That still leaves the mystery of what changed in ProFTPd, because this > was working since 2016. But I'm hoping the customer does not have the > path set to /web, and that changing it will resolve the problem for > her. (Note that I suspect the web designer has a branded pro account > from Cushy and the customer is just enrolled as an editor of her site > and therefore can't see or change the configuration.) > > Web designers can be difficult to deal with. They are artists! And > hosting is just a commodity, low skill work by vendor scum who can be > replaced with the snap of a finger. > > -Original Message- > From: Blueonyx On Behalf Of > Michael Stauber > Sent: Thursday, August 1, 2019 1:09 PM > To: blueonyx@mail.blueonyx.it > Subject: [BlueOnyx:23063] Re: CushyCMS and ProFTPD > > Hi Ken, > > > Since the problem started with the ProFTPd bugfix, I'm starting to > > wonder if CushyCMS uses the site cpfr and site cpto commands. That > > seems unlikely, but I can't know for sure without signing up for a > > CushyCMS account myself to try it. The only other explanation I can > > think of is that the bugfix had some unanticipated consequences or > collateral damage. > > Yeah, it sure is related to the update. The ProFTPd we're using now is > a "release candidate" and I also observed that it does a few things > slightly different than the last stable version that we were using. > The code maturity seems to have dropped a notch or two. > > I don't have any other or better solution at the moment, sorry. But > perhaps you might temporarily go back to the last ProFTPd version that > worked for you? > > If so, please do this: > > rpm -e --nodeps proftpd > rm /etc/proftpd.conf > rm /etc/proftpds.conf > > That removes ProFTPd. Then you can grab the last good one. As I don't > know which version of BlueOnyx you're using I'll be pointing you to > the RPMs of the individual BlueOnyx versions: > > 5209R: > > http://updates.blueonyx.it/pub/BlueOnyx/5200R/el7/blueonyx/x86_64/RPMS > /pro > ft > pd-1.3.5e-1BX7.x86_64.rpm > > 5208R: > > http://updates.blueonyx.it/pub/BlueOnyx/5200R/el6/blueonyx/x86_64/RPMS > /pro > ft > pd-1.3.5-1BX5.x86_64.rpm > > 5207R: > > http://updates.blueonyx.it/pub/BlueOnyx/5200R/el6/blueonyx/i386/RPMS/p > roft > pd > -1.3.5-1BX5.i386.rpm > > Install the RPM of ProFTPd applicable to your BlueOnyx version this way: > > rpm -hUv > > Then restart CCEd and xinetd: > > /usr/sausalito/sbin/cced.init restart > service xinetd restart > > To prevent YUM from updating ProFTPd again please edit /etc/yum.conf > and find the lines that look like this: > > ## start-yum-gui > exclude= > ## stop-yum-gui > > Change it to this: > > ## start-yum-gui > exclude=proftpd > ## stop-yum-gui > > You actually can edit that via the GUI, too. It's under "Software Updates" > / > "YUM Updater" and in the "Settings" tab there is the form field > "Exclude these RPMS". Instead of editing /etc/yum.conf you can > directly write "proftpd" (without quotes) into that formfield to have > it excluded from YUM Updates. > > -- > With best regards > > Michael Stauber > ___ > Blueonyx mailing list > Blueonyx@mail.blueonyx.it > http://mail.blueonyx.it/mailman/listinfo/blueonyx > > > ___ > Blueonyx mailing list > Blueonyx@mail.blueonyx.it > http://mail.blueonyx.it/mailman/listinfo/blueonyx ___ Blueonyx mailing
[BlueOnyx:23079] Gmail problems... again
Greetings! I have had this problem before. Mail from a BlueOnyx 5209R connected via Spectrum has problems sending email to addresses at gmail.com: The original message was received at Wed, 31 Jul 2019 01:28:13 -0400 from b0..org [96.11.xx.xx] - The following addresses had permanent fatal errors - (reason: 550-5.7.1 [2607:fcc8:a28b:1700:a6bf:1ff:xxx:xx] Our system has detected that) - Transcript of session follows - ... while talking to gmail-smtp-in.l.google.com.: DATA <<< 550-5.7.1 [2607:fcc8:a28b:1700:a6bf:1ff:xxx:xx] Our system has detected that <<< 550-5.7.1 this message does not meet IPv6 sending guidelines regarding PTR <<< 550-5.7.1 records and authentication. Please review <<< 550-5.7.1 https://support.google.com/mail/?p=IPv6AuthError for more information <<< 550 5.7.1 . c3si8345ioq.99 - gsmtp 554 5.0.0 Service unavailable Another BlueOnyx 5209R connected at a co-location site has always been able to send email to gmail.com addresses without problem. When I brought this issue up before the solution was to run the following two commands: sysctl -w net.ipv6.conf.all.disable_ipv6=1 sysctl -w net.ipv6.conf.default.disable_ipv6=1 However that does not seem to have the same joyful effect. Any ideas? TIA ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23078] Re: CushyCMS and ProFTPD
Hi Ken, have you checked if the entra "DefaultChdir/web" is still included in your /etc/proftpd.conf (resp. /etc/proftpds.conf)? This is the entry needed for changing directory to /web by default. Maybe this has changed through the update of proftpd? Regards, Tobias > -Original Message- > From: Blueonyx [mailto:blueonyx-boun...@mail.blueonyx.it] On Behalf Of Ken > Hohhof > Sent: Friday, August 02, 2019 2:48 PM > To: 'BlueOnyx General Mailing List' > Subject: [BlueOnyx:23076] Re: CushyCMS and ProFTPD > > It sounds like there was a genuine vulnerability that was fixed, so I'm > reluctant to roll back the update in order to accommodate one customer. > > Yesterday I signed up for a free Cushy account so I could reproduce and > troubleshoot the problem. To my surprise ... no problem! > > Here's my best guess, I think the customer's web designer who set up the > CMS > probably used / as the path, while I used /web. And perhaps this was > causing Cushy to explore directories not owned by the siteadmin, like > maybe > php.d. > > That still leaves the mystery of what changed in ProFTPd, because this was > working since 2016. But I'm hoping the customer does not have the path > set > to /web, and that changing it will resolve the problem for her. (Note > that > I suspect the web designer has a branded pro account from Cushy and the > customer is just enrolled as an editor of her site and therefore can't see > or change the configuration.) > > Web designers can be difficult to deal with. They are artists! And > hosting > is just a commodity, low skill work by vendor scum who can be replaced > with > the snap of a finger. > > -Original Message- > From: Blueonyx On Behalf Of Michael > Stauber > Sent: Thursday, August 1, 2019 1:09 PM > To: blueonyx@mail.blueonyx.it > Subject: [BlueOnyx:23063] Re: CushyCMS and ProFTPD > > Hi Ken, > > > Since the problem started with the ProFTPd bugfix, I'm starting to > > wonder if CushyCMS uses the site cpfr and site cpto commands. That > > seems unlikely, but I can't know for sure without signing up for a > > CushyCMS account myself to try it. The only other explanation I can > > think of is that the bugfix had some unanticipated consequences or > collateral damage. > > Yeah, it sure is related to the update. The ProFTPd we're using now is a > "release candidate" and I also observed that it does a few things slightly > different than the last stable version that we were using. The code > maturity > seems to have dropped a notch or two. > > I don't have any other or better solution at the moment, sorry. But > perhaps > you might temporarily go back to the last ProFTPd version that worked for > you? > > If so, please do this: > > rpm -e --nodeps proftpd > rm /etc/proftpd.conf > rm /etc/proftpds.conf > > That removes ProFTPd. Then you can grab the last good one. As I don't know > which version of BlueOnyx you're using I'll be pointing you to the RPMs of > the individual BlueOnyx versions: > > 5209R: > > http://updates.blueonyx.it/pub/BlueOnyx/5200R/el7/blueonyx/x86_64/RPMS/pro > ft > pd-1.3.5e-1BX7.x86_64.rpm > > 5208R: > > http://updates.blueonyx.it/pub/BlueOnyx/5200R/el6/blueonyx/x86_64/RPMS/pro > ft > pd-1.3.5-1BX5.x86_64.rpm > > 5207R: > > http://updates.blueonyx.it/pub/BlueOnyx/5200R/el6/blueonyx/i386/RPMS/proft > pd > -1.3.5-1BX5.i386.rpm > > Install the RPM of ProFTPd applicable to your BlueOnyx version this way: > > rpm -hUv > > Then restart CCEd and xinetd: > > /usr/sausalito/sbin/cced.init restart > service xinetd restart > > To prevent YUM from updating ProFTPd again please edit /etc/yum.conf and > find the lines that look like this: > > ## start-yum-gui > exclude= > ## stop-yum-gui > > Change it to this: > > ## start-yum-gui > exclude=proftpd > ## stop-yum-gui > > You actually can edit that via the GUI, too. It's under "Software Updates" > / > "YUM Updater" and in the "Settings" tab there is the form field "Exclude > these RPMS". Instead of editing /etc/yum.conf you can directly write > "proftpd" (without quotes) into that formfield to have it excluded from > YUM > Updates. > > -- > With best regards > > Michael Stauber > ___ > Blueonyx mailing list > Blueonyx@mail.blueonyx.it > http://mail.blueonyx.it/mailman/listinfo/blueonyx > > > ___ > Blueonyx mailing list > Blueonyx@mail.blueonyx.it > http://mail.blueonyx.it/mailman/listinfo/blueonyx ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23077] Re: CushyCMS and ProFTPD
On 8/2/2019 7:48 AM, Ken Hohhof wrote Web designers can be difficult to deal with. They are artists! And hosting is just a commodity, low skill work by vendor scum who can be replaced with the snap of a finger. LOL at this. So true. So. True. -- Chris Gebhardt VIRTBIZ Internet Services Access, Web Hosting, Colocation, Dedicated www.virtbiz.com | toll-free (866) 4 VIRTBIZ ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23076] Re: CushyCMS and ProFTPD
It sounds like there was a genuine vulnerability that was fixed, so I'm reluctant to roll back the update in order to accommodate one customer. Yesterday I signed up for a free Cushy account so I could reproduce and troubleshoot the problem. To my surprise ... no problem! Here's my best guess, I think the customer's web designer who set up the CMS probably used / as the path, while I used /web. And perhaps this was causing Cushy to explore directories not owned by the siteadmin, like maybe php.d. That still leaves the mystery of what changed in ProFTPd, because this was working since 2016. But I'm hoping the customer does not have the path set to /web, and that changing it will resolve the problem for her. (Note that I suspect the web designer has a branded pro account from Cushy and the customer is just enrolled as an editor of her site and therefore can't see or change the configuration.) Web designers can be difficult to deal with. They are artists! And hosting is just a commodity, low skill work by vendor scum who can be replaced with the snap of a finger. -Original Message- From: Blueonyx On Behalf Of Michael Stauber Sent: Thursday, August 1, 2019 1:09 PM To: blueonyx@mail.blueonyx.it Subject: [BlueOnyx:23063] Re: CushyCMS and ProFTPD Hi Ken, > Since the problem started with the ProFTPd bugfix, I'm starting to > wonder if CushyCMS uses the site cpfr and site cpto commands. That > seems unlikely, but I can't know for sure without signing up for a > CushyCMS account myself to try it. The only other explanation I can > think of is that the bugfix had some unanticipated consequences or collateral damage. Yeah, it sure is related to the update. The ProFTPd we're using now is a "release candidate" and I also observed that it does a few things slightly different than the last stable version that we were using. The code maturity seems to have dropped a notch or two. I don't have any other or better solution at the moment, sorry. But perhaps you might temporarily go back to the last ProFTPd version that worked for you? If so, please do this: rpm -e --nodeps proftpd rm /etc/proftpd.conf rm /etc/proftpds.conf That removes ProFTPd. Then you can grab the last good one. As I don't know which version of BlueOnyx you're using I'll be pointing you to the RPMs of the individual BlueOnyx versions: 5209R: http://updates.blueonyx.it/pub/BlueOnyx/5200R/el7/blueonyx/x86_64/RPMS/proft pd-1.3.5e-1BX7.x86_64.rpm 5208R: http://updates.blueonyx.it/pub/BlueOnyx/5200R/el6/blueonyx/x86_64/RPMS/proft pd-1.3.5-1BX5.x86_64.rpm 5207R: http://updates.blueonyx.it/pub/BlueOnyx/5200R/el6/blueonyx/i386/RPMS/proftpd -1.3.5-1BX5.i386.rpm Install the RPM of ProFTPd applicable to your BlueOnyx version this way: rpm -hUv Then restart CCEd and xinetd: /usr/sausalito/sbin/cced.init restart service xinetd restart To prevent YUM from updating ProFTPd again please edit /etc/yum.conf and find the lines that look like this: ## start-yum-gui exclude= ## stop-yum-gui Change it to this: ## start-yum-gui exclude=proftpd ## stop-yum-gui You actually can edit that via the GUI, too. It's under "Software Updates" / "YUM Updater" and in the "Settings" tab there is the form field "Exclude these RPMS". Instead of editing /etc/yum.conf you can directly write "proftpd" (without quotes) into that formfield to have it excluded from YUM Updates. -- With best regards Michael Stauber ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23075] Re: "Easy Migrate" released \o/
Hi Michael, > > With this version I get a new error message: > > > > ERROR: Error during run of '/usr/sausalito/bin/em-helper.pl --vsites' on > source server. > > SSH error: $VAR1 = 'ssh slave failed: timed out'; > > > > Well this is pointing into a new direction now. Does it help you in > finding the reason? > > Yeah, this helps. This means that the OpenSSH on the source server > didn't respond back in time and the connection timed out. > > This is pretty weird. Do you have a somewhat unusual SSHd configuration > on the source server? Or is it (network wise) far away and on a bad > connection? It might be worth it to activate SSH keep alive and see if > that helps. > > Here is a guide for that: > > https://patrickmn.com/aside/how-to-keep-alive-ssh-sessions/ unfortunately this didn't help. I still get the same error (after about 2:30 min). Are you going to start a SSH session from the source system on? Then it might be worth to mention that both systems are working on non standard ssh ports. Another thing that might be the reason: the database export on the source system itself takes some time: one of the databases is of 6.7 gig exported size - that's the reason of the more than 2 minutes time the first step of the export takes. Regards, Tobias > > -- > With best regards > > Michael Stauber > ___ > Blueonyx mailing list > Blueonyx@mail.blueonyx.it > http://mail.blueonyx.it/mailman/listinfo/blueonyx ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23074] Re: Time difference
Hi Michael,
>
> Hi Colin,
>
> > I wonder if anybody can help with a weird time problem?
> >
> > Customer has a webpage which writes to a MySQL database (for employee
> clocking on and off).
> >
> > This has been working fine for a couple of years and now they are seeing
> > a18-
> 20 minute difference between the time when the employee clocks in (showing
> on web page) and the time recorded on the database!
> > Server is not under any strain -- time zone is correct.
>
> Twenty minutes is also an odd time-delta. If it was in full hours I might
> suspect
> that perhaps PHP or the server itself is operating on the wrong time zone. But
> 20 minutes? That's really odd.
>
> The question here is: What generates the time stamps? Are these MySQL time
> stamps or are they generated by PHP or another application and are then
> inserted into MySQL as is?
Customer says: " I was using mysql timestamp "now()" in the mysql query. I
changed this to a php timestamp "$now = date("Y-m-d H:i:s");" and it remains
the same."
If we reboot the server then it comes right but over the day, the 'clock' and
'date' results get out of sync again.
The server is a VM on an ESXi host and all hardware uses the domain controller
for NTP.
I have checked the host and domain controller times and they are in sync.
Hwclock is in line with the host time.
Odd ...
Thanks
Colin
___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23073] Re: "Easy Migrate" released \o/
Hi Tobias, > You actually seem to have a version 0.0.6 deployed. Yeah, the 0.0.5 added more debugging and fixed an import problem if the Vsite group changed. The 0.0.6 now also imports Subdomains and had some additional 5210R -> 5209R migration fixes. > With this version I get a new error message: > > ERROR: Error during run of '/usr/sausalito/bin/em-helper.pl --vsites' on > source server. > SSH error: $VAR1 = 'ssh slave failed: timed out'; > > Well this is pointing into a new direction now. Does it help you in finding > the reason? Yeah, this helps. This means that the OpenSSH on the source server didn't respond back in time and the connection timed out. This is pretty weird. Do you have a somewhat unusual SSHd configuration on the source server? Or is it (network wise) far away and on a bad connection? It might be worth it to activate SSH keep alive and see if that helps. Here is a guide for that: https://patrickmn.com/aside/how-to-keep-alive-ssh-sessions/ -- With best regards Michael Stauber ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23072] Re: Easy Migrate "Compass_webapps" error
Hi Don, > [ERROR] Failed to update settings of Vsite NameSpace 'Compass_webapps' > of Vsite monitor.-redacted-.com What BlueOnyx versions are you migration from and to? Does the target of the migration have the NewLinQ and the WebApps PKGs installed? Also: Please take a look at /var/log/messages and send me the SET or CREATE transaction that caused the error. P.S.: If Easy-Migrate fails during a run: You can simply run it again. Don't delete the partially migrated Vsite or any users. It'll deal with them during the next run and will update and complete the existing settings of a partially migrated Vsite. -- With best regards Michael Stauber ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:23071] Re: "Easy Migrate" released \o/
Hi Michael, You actually seem to have a version 0.0.6 deployed. With this version I get a new error message: ## ┌──┐ │ Easy Migrate Helper: Easily Migrate between BlueOnyx Servers │ └──┘ # Checking connection to Source Platform: ltr2 [SSH_OK] SSH connection successfully established. [SOURCE_OK]: Source System (ltr2.cbxnet.de) is a BlueOnyx 5208R and is supported by Easy Migrate. [MIGRATION_START] Starting Migration of Vsite www.mordvinov.org ERROR: Error during run of '/usr/sausalito/bin/em-helper.pl --vsites' on source server. SSH error: $VAR1 = 'ssh slave failed: timed out'; ## Well this is pointing into a new direction now. Does it help you in finding the reason? Schöne Grüße, Tobias > -Original Message- > From: Blueonyx [mailto:blueonyx-boun...@mail.blueonyx.it] On Behalf Of > Michael Stauber > Sent: Friday, August 02, 2019 1:12 AM > To: blueonyx@mail.blueonyx.it > Subject: [BlueOnyx:23069] Re: "Easy Migrate" released \o/ > > Hi Tobias, > > > the output is one line, 24820 characters long. Saved to a file that file > has 24821 byte. > > I just created a script that auto-created 120 additional Vsites on a > 5209R that already had 20 Vsites. > > I then tried to import a single Vsite: > > -- > CT-4e767594 /# /usr/sausalito/sbin/easy-migrate.pl --source > 5209r.smd.net --p 22 --ip 38.114.102.21 --vsites banana.smd.net > ┌──┐ > │ Easy Migrate Helper: Easily Migrate between BlueOnyx Servers │ > └──┘ > > # Checking connection to Source Platform: 5209r.smd.net > > [SSH_OK] SSH connection successfully established. > > [SOURCE_OK]: Source System (5209r.smd.net) is a BlueOnyx 5209R and is > supported by Easy Migrate. > > [MIGRATION_START] Starting Migration of Vsite banana.smd.net > mysqldump: Got error: 1049: "Unknown database 'z'" when > selecting the database > mysqldump: Got error: 1049: "Unknown database 'vsite_site3_db'" when > selecting the database > mysqldump: Got error: 1049: "Unknown database 'vsite_site5_db'" when > selecting the database > [INFO] Vsite banana.smd.net created. > [INFO] Configuring NameSpace 'USERWEBS' 'SiteStats' 'REDIRECT' 'CGI' > 'Java' 'SSI' 'DNS' 'MYSQL_Vsite' 'UserDefaults' 'PHPVsite' 'Shell' > 'Disk' 'Nginx' 'FTPNONADMIN' 'PHP' 'subdomains' > > [WARN] Several NameSpace's of this Vsite could not be set. You might not > have the PKGs for these installed: prestashop, b2evolution, moodle, > sugarcrm, drupal, tcexam, mediawiki, limesurvey, oscmax, racktables, > dolphin, dalbum, template, webtrees, cmsmadesimple, xoops, > Compass_webapps, tiki, osticket, roundcubemail, kimai, eramba, > waphpMyAdmin, e107, lepton, phpbb, smf, wordpress, bandwidthmeter, > magento, ac, mantisbt, webcalendar, solbackup, coppermine, gallery, > owncloud, opencart > > > [INFO] Importing Files of Vsite banana.smd.net > [INFO] Starting RSYNC from 5209r.smd.net:22:/home/.sites/90/site11/web/ > to /home/.sites/90/site11/web/ > [INFO] Starting RSYNC from 5209r.smd.net:22:/home/.sites/90/site11/sql/ > to /home/.sites/90/site11/sql/ > [INFO] Starting RSYNC from > 5209r.smd.net:22:/home/.sites/90/site11/awstats/ to > /home/.sites/90/site11/awstats/ > [INFO] Starting RSYNC from > 5209r.smd.net:22:/home/.sites/90/site11/php.d/ to > /home/.sites/90/site11/php.d/ > [INFO] Starting RSYNC from > 5209r.smd.net:22:/home/.sites/90/site11/webapps_backup/ to > /home/.sites/90/site11/webapps_backup/ > [INFO] Starting RSYNC from > 5209r.smd.net:22:/home/.sites/90/site11/webalizer/ to > /home/.sites/90/site11/webalizer/ > [INFO] Starting RSYNC from 5209r.smd.net:22:/home/.sites/90/site11/logs/ > to /home/.sites/90/site11/logs/ > [INFO] Configured NameSpace 'SSL' of Vsite banana.smd.net. > [INFO] Importing 'vsite_ObUwNw2_db' SQL database of Vsite banana.smd.net > > Done! > -- > > I also ran "/usr/sausalito/bin/em-helper.pl > /tmp/out.txt" and checked > how big the resulting file was. It turned out to be a whopping 1.8 MB > and easy-migrate.pl on the source server had no issues with that. > > So I'm afraid that the size of the dump isn't the problem. In which case > another unknown issue is throwing a wrench into things in your case. > > I've just published easy-migrate v0.0.5-1, which fixes another issue. > I've added some more debugging lines to it and would appreciate it if > you try again. This time around we should be able to see exactly which > error "$ssh->capture()" runs into. > > -- > With best regards > > Michael Stauber > ___ > Blueonyx mailing list > Blueonyx@mail.blueonyx.it >
