I would like to know if Informatica can be used on Windows system ? If so what are the prerequisites?
Both the previous answers are wrong.
Windows 10 is supported for installing the client tools only.
For exact details which Windows server versions are supported, please log on (after initial sign-up if you haven't already done so) to the Informatica Network at https://network.informatica.com ; there's a section named Product Availability Matrices, here you find for each PowerCenter version the so-called Product Availability Matrix (PAM) indicating which Windows versions are supported for server installation and for client installation. You need both, and you can install both on the same Windows server system.
I won't go into this ugly ancient flame war here. Be it enough to say that some people managed to install the server part on Windows 10, but very few ever made it work reliably (in most cases the installation seems to work but doesn't, at latest after the next system restart). I wouldn't waste one single second trying to do so, it's not worth the time.
Related
I am trying to install Oracle SOA Suite 11g but I face the following problem during installation. There are some prerequisites marked as failed. I am wondering why the overall result of the check is not executed. In addition, I have a problem starting the SOA managed server later.
I cannot see the "SOA" folder here
Clearly, if you ignore the checks and SOA does not appear something is broken. You need to tell us your OS version and make sure you adhere to the installation instructions here. My guess is you're on some linux distro. There are many files that need to be installed in many cases on linux to make this work.
I suggest, unless you have to install directly on your OS, to use a prebuilt virtual image to get up and running quickly.
SOA Suite 12c prebuilt is here. Install virtual box (free) and then follow download instructions exactly.
Here is 11g.
Oracle recommends ignoring the results of these checks for some of it's products, although I couldn't find a specific reference to SOA product, you can try to just go ahead and continue with the installation, hoping it will run successfully.
Here's is a reference to Oracle's reference for installation issues -
http://docs.oracle.com/cd/E23943_01/doc.1111/e14771/install.htm#BABCCGAB
You can find an instruction to ignore these errors under the 2.1.6 Oracle Universal Installer Issues section, although I'm not sure they apply in your case.
I have some free-standing C++ code (i.e. not a Windows program) that needs to identify the version of Windows that is installed on a PC.
I can easily differentiate between the different Windows client releases by kernel version (e.g. GetFileVersionInfo on ntoskrnl.exe), however I'm wondering if there's a reliable way to distinguish between a client and server installation.
A problem arises when using this method to distinguish between Windows Vista SP2 and Windows Server 2008 SP2 (6.0 build 6002 the both of them) and Windows 7 and Windows Server 2008 R2 (6.1 build 7600 for RTM and 6.1 build 7601 for SP2, both). What is a reliable (and preferably as straight forward as possible, avoiding the registry would be great as access to Win32 API is not available) method of identifying client vs server OSes correctly for code running outside the environment?
I suppose I could check for files only present on the server edition (what's a good file guaranteed to be on any server edition install, regardless of configuration?), check the Panther folder (which is safe to delete, so no guarantees there), etc. but I'm sure this is a problem that people have run into before and (hopefully) solved more elegantly?
(Sidenote: this question has been asked on SO before, but the solution (WMI) is inapplicable for out-of-band checking)
I'm not entirely sure what you mean about out of band checking, so I'm going to ignore that for the moment.
The normal way would be to call GetVersionEx, and look at the wProductType member of the OSVERSIONINFOEX.
A PE image does NOT specify whether the image should work on a client or server. It only specifies the runtime requirements regarding subsystem, dependencies, memory, affinity, etc...
I ended up searching for a number of binaries in the system32 directory that are generally associated with the Server Edition of Windows. It's not very clean, but in practice it works very well.
If I wanna authenticate windows accounts to AD when a user browses to an apache-running site on a Linux server, here are the usual suspects:
List item
mod_ntlm (which I used in a distant past) - last update on 2003
mod_auth_ntlm_winbind - last update on 04/2007
mod_auth_kerb - last update on 12/2008
No luck getting any of those to work with a recent, fully patched, windows 2000 AD server.
Do you have any clues as to a recipe that does work?
-Peter
-- UPDATE
my current build environment is this:
OS: Ubuntu Lucid
Apache 2.2.14 (from repos)
the auth modules I recompiled from source.
Did you just try to drop binary modules onto an existing apache binary, or did you rebuild Apache and the modules from source on your system?
The last time I did this (admittedly 3+ years ago), I found a combination of Apache+mod_ntlm that worked, but I ended up using a less-than-current version of Apache, in order to match the version of mod_ntlm that I found. My conclusion at the time was that if I wanted current, I was going to have to rebuild Apache and mod_ntlm from source, and I didn't have the time to do that.
Unfortunately, that was two jobs ago, and I don't have access to the configuration details.
LDAP. Active Directory should speak the LDAP protocol well enough (although, I believe Novell's eDirectory sticks to the spec better) that you can use LDAP authentication setups to communicate with it. It'll be a lot easier than fussing around with the Windows-centric NTLM garbage.
See this site for an example:
http://www.jejik.com/articles/2007/06/apache_and_subversion_authentication_with_microsoft_active_directory/
The other, likely costly option, is to invest in an identity manager product. Novell, Sun (now Oracle), and IBM all make one. I suspect that, unless you're designing something for a mid-size corporate project, you won't need these. But, they are an option to consider.
As a guy who frequently switches between QA, build and operations, I keep running into the issue of what to do about operating system updates on the build server. The dichotomy is the same on Windows, Linux, MacOS or any other o/s that can update itself via the internet:
The QA team wants to keep the build server exactly as it is from the beginning of the product release cycle to the end, since installing updates could destabilize the server and means that successive builds aren't made against the same baseline.
The ops team wants the software to be deployed on a system with all the latest security patches; this can mean that the software isn't deployed on exactly the same version of the o/s that it was built on.
I usually mitigate this by taking release candidate builds and installing them on a test server that has a completely up-to-date o/s, repeating the automated tests that are run on the build server and doing some additional system level testing to make sure everything looks good before deployment. However, this seems inefficient to me; does anyone have a better way ?
Personally i don't think you have much of an issue here - just apply the latest updates to the build server. The main reasons i say this are:
it is highly unlikely that your code or any of the dependencies on the build server are so tightly coupled to the OS version that installing regular updates is going to affect anything, let alone break it. There can be minor differences between window messages etc between Windows versions, but those are few and far between, and are usually quite well documented out there on teh interweb. If you are using managed technology stacks like WPF/Silverlight or ASP.Net and even mostly Winforms then you will be isolated from these changes - they should only affect you if you are doing hardcore stuff using the WinAPI directly to create your windows or draw your buttons.
it is a good practice to always engineer your product against the latest version of the OS, because you need to encourage your customer to implement those updates too - IOW you should not be in a position where you have to say to your client to not install update xyz because your application will not run against it - especially if that update is a critical security update
testing for differences between OS versions should be done by the QA team and should independant of what is on the build server
you do not want your build server to get in to such a state that it has been so isolated from the company update process that when you finally do apply them all it barfs and spits molten silicon everywhere. IOW, the longer you wait to update, the higher the risk of something going wrong and doing so catastrophically. Small and frequent/incremental updates are lower risk than mass updates once per decade :)
The build server updates that you do have to be cautious about are third party controls or library updates - they can frequently contain breaking changes or considerably altered behavior. They really should be scheduled, and followed up by a round of testing looking for any changes.
Virtualize!
Using stuff like VMWare Server you can script the launch and suspend of virtual machines. So you can script VM resume, SSH to launch build, copy, VM suspend, repeat. (I say this, but I abandoned my work on this. Still, I was making progress at the time.)
Also, you can trust your OS vendors. Can't you?
They have an interest in compatibility. If you build on Windows XP it is almost certain to work on XP SP3 and Vista and Windows 7.
If you build on RedHat Enterprise 5, it had better work on 5.1, 5.2, 5.3, 5.4, etc.
In my experience this has worked out OK so far for me and I recommend building on your lowest patch OS versions. With the Linux stuff in particular I have found newer releases linking to more recent libraries not available on older versions.
Of course it doesn't hurt to test your code on a copy of the deployment server. It all depends on how certain you want to be.
Take the build server off the network, that way you do not need to worry about installing security updates. Only load the source from CD, thumb drive or whatever other means.
Plug it back in at the end of your release cycle and then let all the updates take place.
Well, for the most stable process, I would have two build servers, "Build with Initial config, Build with update config", and two autotest test servers with similar differences. Use virtualization to do this effectively and scriptably.
I have decided to go with Subversion for a source control repository for my personal and side projects and I'm now trying to decide what OS to use. Currently my file server for my home network is Windows 7 beta. I'm wondering if I should wipe it and install Windows Server 2008 instead? Basically I'd like to know if there are things I could take advantage with a server OS that I can't with Windows 7. First thing that comes to mind is accessing subversion remotely with a VPN connection.
I'm a .net developer, but have dabbled in Linux a bit so I'm not completely turned off to the idea of an ubuntu or debian server...
I imagine the installation and configuration process might go off with fewer hitches if installed on Linux, just because of the package management, but that's assuming some experience with the package system of $whatever_distro. If you're comfortable with Windows, Subversion works perfectly well on there. I've set it up on both, but prefer the Linux installation process (easier Apache integration, in my view), but I had pre-existing Linux experience.
If you're familiar with Windows, I bet you'll find the installation and configuration process easier there. As others have said, many of the tools are cross-platform.
You can run a Subversion server on Windows or Linux (or whatever) so it really doesn't matter. Pick whichever one you already have and feel most comfortable with. Since you are a Windows developer I see no real reason to toss Linux into the mix though.
If your goal is to minimize the amount of work you put into the maintenance of subversion, go with the OS you are most comfortable with. Many maintenance scripts, and subversion hooks are written and available in perl and python which are available for both windows and linux.
One advantage to the Windows server OSes over their client counterparts is that the client OSes are limited as to the number of inbound connections. If you are going to be the only person working on the repo, this may not make a difference. However, if there are multiple people, then this would be an issue. XP Pro/Vista Ultimate are limited by Microsoft to 10 inbound connections. I cannot speak for Windows 7.
To make life easy, try VisualSVN Server. For personal projects there's no reason to setup a separate server just for SVN.
Windows 7 will be able to host Subversion with no problems whatsoever..
If your file-server is already setup and working under Windows 7, I'd say stick with that.. Adding SVN is no reason to install a new OS
You don't need a server at all to use subversion.
If you've already got a file server on your home network, and you're doing this only for you and your personal projects, just use a subversion client such as TortoiseSVN and create your repository (or repositories) on your file server via network share (or mapped network drive, etc).
I wouldn't recommend this for multi-user setups (unless each has their own repository), but for a single user this is the simplest option. And using this approach, to answer your question, you wouldn't gain anything by switching to a server OS such as Windows Server 2008.
I'd actually recommend going with a hosted Subversion provider instead of setting up Subversion on Windows or getting a second server for that purpose. I work for ProjectLocker, but if you Google "subversion hosting", you'll see there are a number of providers that offer free or reasonably priced solutions. The advantages:
It's a hosting provider's primary job to keep your code safe, secure, and accessible, so they focus on uptime, backups, and security monitoring so you don't have to
You don't have to learn how to be a system administrator or Subversion administrator; several providers have user interfaces that make it easy to manage users and permissions.
Hosting instead of DIY lets you focus on what you actually care about: writing great software
I suggest you take a look at ProjectLocker and some of the other providers and decide which one is right for you. You may decide that doing it yourself is the best option for you, but for many people in your situation, a hosted solution has met their needs.