from my slapd.conf file, i see where my data is stored. when I look into that data directory i see two kinds of files, one type are .bdb files which appear to be the data files as that is the extension defined in the config file. But, I also have a bunch of log files, which appear to be binary when I try to read them in vi. I'm not sure if they are supposed to be there or if this is an oversight by someone previous to me. If I want to restore from an .ldif file, am I loosing anything by deleting all the log files? do I just need to delete the bdb files?
They are Berkeley DB files.
On Ubuntu 10.04, for example, you can install the db4.7-util package and get some information using the various db4.7_* utils (e.g. db4.7_dump or db4.7_stat). This being said, the structure of the database really depends on how OpenLDAP is coded (it's an internal format, so it's not particularly useful unless you really want to dig into it).
If you want to restore from an LDIF file, use LDAP clients or OpenLDAP commands such as ldapadd.
Related
MSI database contains set of tables, and I can successfully enumerate File table, which has all deployable file' meta-deta. What I need to extract is the actual contents of those files. msiexec, lessmsi, 7-zip all can do it, but I couldn't find any source/API to do it.
What I've discovered it that all other (resource) files are in Binary table, and Data field can be used to get content of those files (like icons, custom DLL etc).
Further, I found and know that Media table contains information about the .CAB file (MSI has all content embedded with <MediaTemplate EmbedCab="yes"/>. This simply means the CAB file contains the actual content. I probably need to read contents from "Structured Storage" of the .msi file.
How to extract the contents of CAB/MSI file, using native C Msi* functions?
Phil has given you the easy/simple answer but I thought I might give you a little more information since you've done some research. Checkout:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372919(v=vs.85).aspx
This is where the structured storage is. You'll see something like Disk1.cab as the Name (PK) and binary data. The data is a CAB file with the file entry in the cab matching the File.File column. From there you can use the File.FileName column to get the short name and long name (you'll want the long name no doubt) and do a joint to the Component table to get the directory table ID.
You'll also need to recurse the directory table to build the tree of directories and know where to put the files.
Fun stuff. There's some libraries in C# that make this WAY simpler. Or just call msiexec /a as Phil says. :)
The most straightforward to extract all the files to some location is to install the product in "advertised" mode. If you do a:
msiexec /a [path to msi] TARGETDIR=[some folder]
you'll see what happens.
In C++ call MsiInstallProduct () with that command line.
You have gotten many good answers already, including the use of dark.exe from the WiX toolkit. By downloading the WiX source code you should be able to get the code you need ready-made from there. I assume you may already have done this.
Chris has already linked to the DTF code you can check, but here is a link directly to dark.exe as well: https://github.com/wixtoolset/wix3/tree/develop/src/tools/dark. I would try both. This is C#, you seem to want native.
UPDATE: Before I get to the Win32 features you can use, check out this little summary of the C# DTF features: How to programmatically read the properties inside an MSI file?
Native Win32 functions: The database functions to deal with an MSI file can be found on MSDN (this is to deal with the MSI file as a database). There are also MSI Installer Functions (used to deal with the MSI file as an actual installer).
You can certainly find good examples of native code for this with a good Google search. Have fun!
BTW: It would help with a description of the actual problem you are trying to solve as well as what you need technically. There could - as always - be less involved ways to achieve what you need. Unless you are writing a security software or malware scanner or something super-involved.
And so it is clear: WiX's dark.exe fully decompiles MSI files into WiX source files and the resource files used to build them - you can then text and binary compare the various types of content (text compare for tables, binary compare for binaries, etc...). The process to do so via command line is described in the following answer: How can I compare the content of two (or more) MSI files? (this is about comparing MSI files, but one option to do so is to decompile them - see section on dark.exe - just for reference for others who find your question).
I like to link things together so we can find content easily at a later point in time. Strictly speaking it doesn't seem necessary here, you have what you need I think but others could perhaps benefit from some further links. Here are some related links:
Extract MSI from EXE.
What is the purpose of administrative installation initiated using msiexec /a?
How do I extract files from an MSI package? (explains why you should not use 7-Zip to extract).
I am not even sure where to begin with this one. Our old accounting system used Cobol and flat files as a database. I was wondering if there was any way to import all of this into SQL and making it useful. Ideally I would like to get to a point where I could import this historical data into our ERP. The header in one of the files shows a RMKF entry and I also see some Cobol dll files on the server like Cob32api.dll
Any insight appreciated.
Directly no. Any answer will be determined on which Cobol Dialect you have (I would guess RM Cobol). Some of the Cobol compilers have there own File System. You may need to unload the files
In general while some Cobol files will be suitable for loading into a Database. Other will require programming:
Multi-Record files - probably split in to several different tables
Files with redefines
Accessing the data in the files
Loading the Files into a Database is either going to be expensive or time consuming (or both):
There are some commercial that provide access to Cobol Files (I would imagine they are expensive). Googling revealed: http://www.cobolproducts.com/datafile/data-viewer.html popup. But you will still need to analyse the files. Things like redefines can cause issues.
look at this answer Dynamically Reading COBOL Redefines with C# It looks to be similar problem, Thomas used cb2xml to generate the Cobol.
If you get the files into a Text format (see 2 above), cobolToCsv may be useful - Csv files can generally be loaded in to Databases. cobolToCsv will not handle RM-Cobol files directly.
The RecordEditor mentioned by Simon is unlikely to handle RM-Cobol binary files but should handle unloaded Text files. It may prove useful (note I am the author of the RecordEditor)
I have a database file with .DB file extension. I have been googling and it looks like SQLite. I tried to connect to it using SQLite and SQLite3 drivers and I am getting an error "File is encrypted or not a database".
So I dont know if file is encrypted or it is not an SQLite database. Are there any other options what should the .DB extension should be? How do I find out that file is encrypted?
I tried to open it in the text editor and it is mostly a mess of charaters and some times there are words visible. I have uploaded the file here: http://cl.ly/3k0E01373r3v182a3p1o for the closer look.
Thank you for your hints and ideas what to do and how to work with this file.
Marco Pontello's TrID is a great way to determine the type of any file.
TrID is simple to use. Just run TrID and point it to the file to be analyzed. The file will be read and compared with the definitions in the database. Results are presented in order of highest probability.
Just download the executable and the latest definitions file into the same directory and then run TrID:
trid.exe "path/to/file.xyz"
It will output a list of possible file types for the file with a confidence rating. Here's a screenshot of using TrID to analyze a SQLite database file:
There's also a GUI version called TrIDNet:
If you're on a Unix-like platform (Mac OS X, Linux, etc), you could try running file myfile.db to see if that can figure out what type of file it is. The file utility will inspect the beginning of the file, looking for any clues like magic numbers, headers, and so on to determine the type of the file.
Look at the first 30 bytes of the file (open it in Notepad, Notepad++ or another simple text viewer). There's usually some kind of tag or extension name in there.
Both SQLite 2 and SQLite 3 have a very clear message: SQLite format 3 for SQLite 3 (obviously) and This file contains an SQLite 2.1 database for SQLite 2.
Note that encrypted SQLite databases don't have a header like that since the entire file is encrypted. See siyw's comment below.
On a Unix-like system (or Cygwin under Windows), the strings utility will search a file for strings, and print them to stdout. Might help you narrow the field.
There are a lot of programs besides database programs that use a "db" extension, including
ArcView Object Database File (ESRI)
MultiEdit
Netscape
Palm
and so on. Google "file extensions" for some sites that catalog file extensions and the programs that use them.
There's no conclusive way to know, because SQLite encrypts the entire database file, including the header.
Further, there's not a lot of difference to you, except for possible error text to a user if you're prompting them for a password.
I want to essentially make it so that you never need to unzip/unrar any files. Currently, I have a Dokan filesystem which can do it given a specific zip file but I wanted to know how I can make it apply to all files. Meaning, I want to be able to compile a program that has "fopen("test.zip/1.jpg", "rb");". I think that a Shell Extension would work for dynamically loading the file into the filesystem IF I were browsing in the shell explorer but that doesnt help me with the fopen example. Any ideas?
What you want to do can be used with help of file system filter driver, which would track directory enumeration requests and report directories in place of ZIP files. Then this driver would create virtual files and take the data from ZIP archives. Quite a lot of kernel-mode work, I should say. And file system filter driver is not a file system driver, so dokan won't help you at all.
Is there a tool that creates a diff of a file structure, perhaps based on an MD5 manifest. My goal is to send a package across the wire that contains new/updated files and a list of files to remove. It needs to copy over new/updated files and remove files that have been deleted on the source file structure?
You might try rsync. Depending on your needs, the command might be as simple as this:
rsync -az --del /path/to/master dup-site:/path/to/duplicate
Quoting from rsync's web site:
rsync is an open source utility that
provides fast incremental file
transfer. rsync is freely available
under the GNU General Public License
and is currently being maintained by
Wayne Davison.
Or, if you prefer wikipedia:
rsync is a software application for
Unix systems which synchronizes files
and directories from one location to
another while minimizing data transfer
using delta encoding when appropriate.
An important feature of rsync not
found in most similar
programs/protocols is that the
mirroring takes place with only one
transmission in each direction. rsync
can copy or display directory contents
and copy files, optionally using
compression and recursion.
#vfilby I'm the process of implementing something similar.
I've been using rsync for a while, but it gets funky when deploying to remote server with permission changes that are out of my control. With rsync you can choose to not include permissions, but they still endup being considered for some reason.
I'm now using git diff. This works very well for text files. Diff generates patches, rather then a MANIFEST that you have to include with your files. The nice thing about patches is that there is already an established framework for using and testing these patches before they're applied.
For example, with patch utility that comes standard on any *unix box, you can run the patch in dry-run mode. This will tell you if the patch that you're going to apply is actually going to apply before you run it. This helps you to make sure that the files that you're updating have not changed while you were preparing the patch.
If this is similar to what you're looking for, I can elaborate on my process.