I am using postgresql-9.4 (port 5432) and postgresql-10.0 (port 5433) on my Linux machine (RHEL 7.4). Postgresql-9.4 was installed using yum repository and Postgresql-10.0 was installed using source in different partitions.
I have taken a backup of db (dtbase.backup) on Postgresql-9.4 using it's pg_dump and trying to restore this on Postgresql-10.0 using it's pg_restore.
While doing this, I am getting below error:
pg_restore: [archiver] unsupported version (1.13) in file header
I have checked different forums but unable to find the solution. Any help would be highly appreciated.
You'll have to upgrade your PostgreSQL v10 to 10.3 so that you have commit b8a2908f0ac735da68d49be2bce2d523e363f67b:
Avoid using unsafe search_path settings during dump and restore.
Historically, pg_dump has "set search_path = foo, pg_catalog" when
dumping an object in schema "foo", and has also caused that setting
to be used while restoring the object. This is problematic because
functions and operators in schema "foo" could capture references meant
to refer to pg_catalog entries, both in the queries issued by pg_dump
and those issued during the subsequent restore run. That could
result in dump/restore misbehavior, or in privilege escalation if a
nefarious user installs trojan-horse functions or operators.
This patch changes pg_dump so that it does not change the search_path
dynamically. The emitted restore script sets the search_path to what
was used at dump time, and then leaves it alone thereafter. Created
objects are placed in the correct schema, regardless of the active
search_path, by dint of schema-qualifying their names in the CREATE
commands, as well as in subsequent ALTER and ALTER-like commands.
Since this change requires a change in the behavior of pg_restore
when processing an archive file made according to this new convention,
bump the archive file version number; old versions of pg_restore will
therefore refuse to process files made with new versions of pg_dump.
Security: CVE-2018-1058
Your 9.4 installation already uses archive format 1.13, which your v10 installation does not yet understand.
Besides, you should always use pg_dump from the higher PostgreSQL version to upgrade a database.
Related
I've done a bit of googling and haven't been able to find any documentation on this, but I need to upgrade my Seeddms (Document Management System) server from 5.1.25 to 6.0.19.
I am running a Linux Lamp 4.19.0-19-amd #1 SMP Debian 4.19.232-1 (2022-03-07) with a Seeddms web server on it.
I tried copying the contents of the .gz download file of the latest version over my current /var/www/html/dms/ folder and it didn't work, I did a similar thing to update my dokuwiki site so I thought I'd give it a try here.
I am still new to Linux so any advice would be greatly appreciated!
I was able to find the solution, in the seeddms-quickstart-x.x.x/seeddmsxxx/seeddms-x.x.x/doc/README.Install.md.
Here is what is says on upgrading versions if anyone has trouble with this as well. Make sure your server meets the requirement as well.
UPGRADING FROM A PREVIOUS VERSION OF SEEDDMS
As SeedDMS is a smooth continuation of LetoDMS there is no difference
in updating from LetoDMS or SeedDMS.
You have basically two choices to update SeedDMS:
you install a fresh version of SeedDMS and copy over your data and configuration
you replace the software in your current installation with a new version
The first option is less interuptive but requires to be able to set up a second
temporary SeedDMS installation, which may not be possible, e.g. because of storage
limitations. It can be the only option if you change servers.
The first update procedure is only needed if the version changes on the minor
or major version number. Changes in the subminor version number will never
include database changes and consequently it is sufficient to use the existing
data directory and database with the new version. Choose the second update
option in this case.
In both cases make sure to have a backup of your data directory, configuration
and database.
Fresh installation and take over of data
The first update option is to set up a new instance of SeedDMS and once
that is running take over the data from your current (old) instance.
just do a fresh installation somewhere on your web server and make sure it
works. It is fine to use
SQLite for it, even if your final installation uses MySQL.
replace the data directory in your new installation with the data directory
from your current installation. Depending on the size of that directory (and
whether the new installation is on a new server or the old server) you
may either copy, move or place a symbolic link. The content of the data directory
will not be changed during the update. Its even perfectly save to
browse through your documents and download them after finishing the
update. The data directory will not be modified until you actually modify
documents.
copy over the configuration settings.xml into your new installation. This will
effectively make your new installation use the data from your old installation,
because all paths are still pointing to the old installation.
if you use mysql you could as well make a copy of the database to make sure
your current database remains unchanged.
modify the settings.xml to fit the environment of the new installation.
This will mostly be the
httpRoot, the paths to the installation directory and possibly the database
connection.
create a file ENABLE_INSTALL_TOOL in the conf directory and point
your browser at http://hostname/seeddms/install
The install tool will detect the version of your current SeedDMS installation
and run the required database updates.
If you update just within the last version number (e.g. from 5.1.6 to 5.1.9),
this step
will not be required because such a subminor version update will never
contain database updates.
Upgrading your current installation
Instead of setting up a new installation, you may as well replace the php files
in your current installation with new versions from the quickstart archive.
get the SeedDMS quickstart archive seeddms-quickstart-x.y.z.tar.gz and
unpack it somewhere on your disc.
copy the directory seeddms-x.y.z from the unpacked archive into your
current installation and make the link seeddms point to this new directory.
copy the directory pear from the unpacked archive into your current
installation, replacing the existing directory. Make a backup of pear before
the replacement if you want to ensure to be able to go back to your old version.
you may compare your conf/settings.xml file with the shipped version
conf/settings.xml.template for new parameters. If you don't do it, the next
time you save the configuration the default values will be used.
create a file ENABLE_INSTALL_TOOL in the conf directory and point
your browser at http://hostname/seeddms/install
The install tool will detect the version of your current SeedDMS installation
and run the required database updates.
If you update just within the last version number (e.g. from 5.1.6 to 5.1.9),
this step
will not be required because such a subminor version update will never
contain database updates.
This is an interesting issue that I couldn't identify the cause is from Curl, or SCP or Linux/Hadoop.
Current environment has following command to push a build to Linux/Hadoop environment.
curl -k -v scp://this.is.a.fake.url.com/linux/mount/drive/to/hadoop my-build.app
After providing the correct username and password, the build pushed successfully.
However when I check content of the build, it is a file from previous release (an old version that was uploaded before). It almost feels like there is buffer mechanism either by Curl or linux/hadoop to keep old build (which must be stored somewhere)
I also found an interesting observation that if I delete existing build in Hadoop/Linux before the CURL command, the issue never occur again. So the problem is when using Curl to upload and replace existing file, make fresh upload without existing file is always successful
Just wondering anyone had the similar experience.
Well, HDFS files are read only. You don't modify files, you either append, or replace --> (create new, Delete old, rename to the same file name.) This is consistent with what you are seeing, and likely there is a lost error message in your mount tooling. (As it's not possible to modify it must be silently failing)
I'm quite new in the InstallShield stuff, I took this project from a leaving co-worker. However, here's my problem:
I was trying to update a MySQL Server with the setup from 5.7.17 to 5.7.19, which works great most of the times.
I got the feature "MySQL", splitted in "MySQL Data" (includes the performance_schema and mysql database), "MySQL Service" (Service batch files) and "MySQL Binaries" (the files).
For the update, I just changed the binaries by the new one and left the rest. All features are selected and my log tells me, that it installs all files which it hasn't installed by now, leaving the existing files untouched. As this is an update, it seems correct to me.
But sometimes, at the end of the setup process, it uninstalls almost anything of my MySQL Feature again; the databases, the batch files and almost any core file which wasn't changed by the setup before. But why is that and how can I stop my setup from do so?
Kind regards
I think what you're describing is that your file containing the data is not getting updated. Since this type of file cannot be versioned, that's what Windows installer uses to determine whether or not to upgrade the file, you will need to mark the component containing this file to Always Overwrite. Check out the MS docs for the Component table for how to do this with the Attributes field.
You may want to check the conditions on the components in question. Also, check the install sequence to see if it is calling uninstall out of sequence.
I have a broken installation of Ubuntu 14.04 - it won't boot, but I won't say anymore about that because that's not what I'm asking about really. I have a MySQL database (created using v5.5) on the broken Ubuntu installation and I need that data. I can get at the raw MySQL database files by mounting the broken installation onto another machine.
I actually need the database to be imported into a MySQL v5.1 installation. I tried copying the raw database files (e.g. the directory at /var/lib/mysql/dbname) into the same directory on the working OS installation. At first, it seemed like it worked, I can see the database, I can use it and I can list the tables. But it turns out that even though I can see the tables in the db, any attempts to describe or use them in any way give the 'table doesnt exist` error.
Ideally, I'd love to be able to use msqldump and then import the database the proper way, but how can I get a dump of the database if it's not part of the MySQL installation (remember, I can't boot into the installation, it's broken).
Of course, mysqldump is the most preferable solution, but if it's not possible to use that utility with the raw database files as input, then I'm willing to try anything that might work.
Of course the first thing you should do is to install the same version of MySQL as the original - if you're directly using the raw data files, keeping things as identical to the original as possible is a must! The same applies to paths, make sure the new installation and data files are placed in the same directory path that they were originally.
Once you have this, you can mysqldump the tables and use that to import into a clean, new installation.
I need inno setup compiler script to check whether mysql server is installed or not before installing the application.
MySQL is quit differ than other ones, we can also use MySQL with out installing into our system by running required services time to time from the downloaded zip archives, extracted files may be placed any where on the system...Tlama Already mentioned this.
Here we have two cases to Check
Case 1:-MySQL is installed or not
Direxists function(Here you can Check whether MySQL directory exists in program files or not )
MySQL directory path :{pf}\MySQL
Filexists function(with this you can check required MySQL files are there in the users systems )
Query the registry with the MySQL registry Key names
HKEY_USERS\S-1-5-21-1707045092-1792370289-147592793-1000\Software\MySQL
HKEY_USERS\S-1-5-21-1707045092-1792370289-147592793-1000\Software\MySQL AB
HKEY_CURRENT_USER\Software\MySQL
HKEY_CURRENT_USER\Software\MySQL AB
check whether these are existed in registry or not.
if Every thing is existed, that's fine. Go for your application installation
if no check for case 2 also
Case 2:- Is there any files or directories with the name of MySQL in the entire system and required services of Mysql are running or not
a. first check whether is there any file or folder exists with the name of MySQL in the users machine by using below commands, to execute commands you can use Exec function
with the below one you can find whether MySQL(file/directory) is there in c drive or not, but not in entire system
C:\>tree |find "mysql" >filename
b)now change the drive to D,E,F by using
below command will give you , all disk drives in the machine
C:\>wmic logicaldisk get caption >filename
then check each and every drive in the above filename
C:\>D:
d:\>tree |find "mysql" >filename
each time Loadstringfromfile to some string and then check the length of string is zero or not.
if not zero, you need to check for required services are running or not by using (you can skip some above steps for simplicity)
tasklist |find "required service of MySQL" >filename
if all drives finished and if did not found any thing, no worries simply prompt user to download MySQL (Use ITD(Innoo tools downloader)) or else you can pack MySQL msi with your application but your application become bulky(Contains more memory).