I am installing Firebird (v1.5.5 - I know it's old but it works) on a new computer which is running Windows 7. I have installed the classic server version as a service. According to documentation at the Firebird site, I modified the firebird.conf file so that IPCName would be global\FirebirdIPI; I did this while the service was not running.
Despite all my efforts, I have been unable to access any of the databases which I copied to this new computer via ISQL. FWIW, the EMS SQL 2005 manager program is successful in accessing the databases, but this program apparently has a direct method which does not require fbclient.dll.
What else should I be checking?
Update from a few days later. After wasting a great deal of time with Windows 7, we decided to downgrade the computer and run XP. After installing the superserver version of FB 1.5.5, I can run my programs and access the databases which are stored on this computer. Attempts to access the databases from other computers connected on the network failed with a variety of error messages, but normally something like 'i/o error for file !firebird!\db\q400.fdb'.
In order to allow people on the network to continue to access the databases, I revived the NT server and started the Firebird service - and all the programs can access these databases successfully from remote computers!
To simplify matters, there are three computers on the network:
the NT server ('zorcomp'), which is running the Firebird service; the fdb files reside on this computer in a directory called 'db' which sits under a shared directory called 'firebird'
a computer running XP, called 'kivserver', which also has a shared directory called 'firebird' and underneath that a directory called 'programs'. Copies of all the fdb files reside in a directory called 'db'.
a computer running XP, which maps \zorcomp\firebird to disk L: and \kivserver\firebird to disk T. From this computer, I can run a program sitting in T:\programs and get it to access successfully a file sitting in L:\db. If I stop the FB service on zorcomp and start the same service on kivserver, the same program cannot access files sitting in T:\db.
I hope this is clear enough. For the life of me, I can't see any difference between all the files which are residing in \kivserver\firebird to those which are sitting in \zorcomp\firebird - but somehow there is a difference!
Obviously, I don't want this arrangement to continue - the NT server has to be retired honourably.
Further edit. I now have the firebird server running on 'kivserver' (NT). I can access the database files locally.
Computers running Win7 can now access these database files using a connection string \\kivserver\firebird\db\database.fdb.
Computers running XP cannot access these database files, although IIRC wisql did succeed with \\kivserver\firebird\db\database.db.
The NT server has been disconnected from the network.
TIA,
No'am
AFAIK EMS SQL uses fbclient.dll (or a wraper around it).
If the only thing you want is to access the databases, I suggest you to do so using TCP protocol instead of the local protocol. To do it connect like this:
c:\>isql localhost:c:\path\to\db.fdb -u sysdba -p masterkey
Unless you're avoiding TCP or the machine have no local interface enabled, it will do the work for you.
Try using this to connect to your database:
hostname:drive:\complete path\filename.fdb
or
\hostname\drive\complete path\filename.fdb
May I know the component you're using?
If your clients are Windows 7 then you might try to use \\hostname\sharename\filename.fdb instead of drive:\filename.fdb connection string.
Several months later, the NT server was somewhat abruptly retired when it displayed 'MBR error' on rebooting after someone unlugged it by accident. Thus I was left with no option but to start running the Firebird server program on 'kivserver'. The connection problems returned.
Eventually I was able to solve the problem with the following connection string
10.0.0.202:e:\firebird\db\manager.fdb
where 10.0.0.202 is the ip address of the server, and e:\firebird\db the directory in which the database sits, relative to the server itself.
I hope that someone else, some time, will find this information useful.
Related
The problem statement:
Suppose there are 20 windows machines within a local network. One of the machines serves as the server and hosts the database. Now, the other 19 machines have the access to read from the server machine, but the server machine does not have username and password for any of the other 19 machines.
I have to update a desktop application installed on all the machine. There is a spring-boot application, hosted on the server machine which downloads the build. Now, as soon as I download the build I have to notify all the other 19 machines that build has been downloaded so that they can read and update themselves.
Solution 1: Install a windows service which will poll the server and check if updates are available.
Solution 2: Host a POST web API on the 19 machines and notify them by making a post call. I think installing IIS or Tomcat on every machine is not viable.
Is there any other optimal solution for notifying the client?
Note: We cannot take the RDP and neither have credentials but we can make use of already deployed windows application on the other 19 clients.
Solution 3: If your machines share the same domain, use msi install packages to update software all across domain by using Group Policy. It's common way.
Solution 4: Launch desktop application directly from server shared folder. It works good while server machine is always accessible and application is not too heavy for your LAN.
Here you need some care about writing new application files while it running on client computers. Good way is to keep a different folders for different versions and launch with shortcut pointing to latest one:
v1.3\app files here
v1.4\app files here
v1.4.6\app files here
v1.7\app files here
app.lnk → v1.7\app.exe
client machines launch the application with app.lnk.
Upd: if you update application when nobody works (see 1am…2am), you can omit all of this versioning stuff.
Solution 1: It work as well. You can use NSSM to easily launch your update script or exe-file as a Windows service.
I would use a windows service or a scheduled task (both could be the same application you provide, but with some arguments). It frequently checks if a new version is available (maybe only once a day).
If you only have a short time frame when the new version has to be installed on all machines you could also provide an installation date with the new version. (Maybe the check will be done through a REST api where the client sends the current installed version number and the server answers with an status code 200 and the body is either empty or provides an json object containing the new version number, the due date and the download url.)
Then the client can already download the new version and make it available on the machine, but it triggers the installation only when the due date is reached. This check of the due date can happen more often, cause all informations are already on the client machine and can be done locally.
After successfully running subversion for years on a Windows 2008 server, I recently moved to Windows 8.1, mainly because the machine does also serve videos to my home network (works fine) and because Windows 8 provides better energy saving on my platform than Windows 2008 server did. So far, so good.
Then I tried to re-install Subversion. I intend to use the built-in server application svnserve.exe. I downloaded the latest windows package, installed it (success), and configured a service (svnserve --service ...) which I can successfully start using the Windows Service Management Console. Port 80 is already taken by a different application, so I let subversion pick 3690, which is fine for me. I used netstat to confirm that svnserve.exe is bound to port TCP:3690, which is listed OK. Just to clear one potential roadblock I also disabled the Windows firewall.
Then I created a sample repository named "test" using svnadmin locally, success as well, a subversion file structure appeared on the harddisk.
Problems arise when I try to access the repository using my local browser (Firefox), an attempt to connect to URLs
http://127.0.0.1:3690[/svn|/svn/test]
all three give me the same cryptical response:
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops atomic-revprops partial-replay inherited-props ephemeral-txnprops file-revs-reverse ) ) )
Somehow I have expected a subversion GUI instead.
Connecting from a remote machine via browser reveals the same useless line of text.
Connecting from a remote machine using my usual Tortoise client gives the message:
Unable to connect to a repository at URL 'http://xxx.xxx.xxx.xxx:3690/svn/test
Error running context: The server unexpectedly closed the connection
I tried to add the --log-file option to svnserve, and indeed a log file appears once I start the service, but it is empty and it remains empty.
Trying to use svnserve -X instead of running it as a service reveals the exact same behavior.
Seems I am stuck. Anyone who has an idea what I can do to get that thing working?
Just to help out another beginner running into the same problem ... I finally found the problem: I simply used the wrong client, svnserve does not support web browsers. Using the Tortoise client, and providing the correct prefix (svn:127.0.0.1/...) was all I had to do.
The long version:
If one wants to work with the simple, reliable, fast, but plain-text and proprietary protocol based) svnserve service, he needs to use a proprietary client, like Tortoise, and the svn: prefix instead of http/https:, and no port, like
svn://mysvnserver/testrepo
If needed, one may even reconfigure svnservice to use authentication and encryption later. svnserve isn't supporting web browsers, if one tries to access svnserve using a web browser like I did he gehts the internals of the svn protocol dumped to the screen.
If one wants to use his web browser, http/https protocol, and niceties, like a user friendly browser based interface and some remote administration capabilities, he must not use svnserve, but install a web server service (like apache) and configure if for use with subversion.
So in the end my problem had nothing to do with Windows 8. It just has slipped from my mind that years ago I went the apache path, while now I decided that the built-in svnserve service was good enough for my needs.
Armin.
I need to use nodejs to write file to a password protected shared folder on a remote machine running Windows server 2008 r2, how can I do impersonation things within nodejs like .net app does?
Thx in advance!!!
PS:
Sorry for the unclear description. The folder is set to shared across the internal network on the remote windows server system, the folder is set to "readonly" for the windows account explicitly created by the admin. The nodejs server is on the same internal network and need to access the remote shared folder, thus I think nodejs need to impersonate the windows account on the remote machine to read contents from the shared folder. My question is how to do the sorry for the unclear description. The folder is set to shared across the internal network on the remote windows server system, the folder is set to "readonly" for the windows account explicitly created by the admin. The nodejs server is on the same internal network and need to access the remote shared folder, thus I think nodejs need to impersonate the windows account on the remote machine to read contents from the shared folder. My question is how to do the impersonation stuff for nodejs?
Late to the party - but since there is no accepted answer...
You'll need to launch your node process using the account that has access to the network share. How this is done differs based on your setup. For example, if you're runnning node on a lLinux server trying to connect to the remote Windows server, then it's not going to be straightforward with node.
However; if you're running node on a Windows server, trying to connect to a remote share on another Windows server (which is what it sounds like your situation probably is). Again, you'll have to run your node script as a user with access to the remote share. If you need to do it from code, I'd suggest taking a look at my module node-windows. It doesn't provide remote share access specifically, but it will allow you to run command line code with a different account from within your node script.
I'm using SSH tunneling to connect from a Windows 7 machine to a remote Postgres database.
The tunnel works fine when I use pgAdmin to connect to the remote database. However, I haven't managed to set up an ODBC DSN to connect to the remote database.
I'm creating a System DSN with the same server address/username/password/port/ssl mode as pgAdmin but when I click "Test" I get: "Could not connect to server; No connection could be made because the target machine actively refused it."
Any ideas on where to start debugging? I've ruled out Windows Firewall and remote server configuration, since I can connect with the exact same information in pgAdmin.
Edit
The problem resolved itself after reinstalling Windows.
When debugging this the first thing to do is to start testing the PostgreSQL server with the psql command line utility. This avoids issues of drivers etc to see what is actually going on. Generally speaking my troubleshooting process is:
Can I ping the server?
Can I connect with psql?
When I test my connection via the control panel, does it work?
Now, assuming the problem is on #2, the first thing I would do is try disabling firewalls on both sides (they can be brought up and tuned after trying with both down). This rules out misbehaving firewalls and if it shows this to be a problem then you have the answer on where to troubleshoot.
In my experience Windows firewall can cause all manner of problems. I have even seen it block web pages halfway through the web page. I don't think you can rule out Windows Firewall based on the information you have provided.
If this happens again, the first things to do include disabling both any antivirus software and firewalls.
The other possibility would be a bad ODBC config (maybe port 5423 instead of 5432) or a badly installed DLL of some sort. The latter may be fixed (or not) using sfc /scannow or reinstalling the odbc driver, or other actions.
I know it is not strictly a programmer question, on the other hand, I would really like to be able to do a simple svn up on the production servers, which would save us a lot of hassle.
Or production servers are within a corporate network, and access is only allowed through a gateway server. From that we can access the actual servers via Remote Desktop. Because of this maintenance unfriendly setup we use a sftp server to get our files to the production server (where the ftp server alwys resets last modified date), so it is complicated to determine which files have changed.
So if it would be possible to setup a ssh tunnel from the actual server through the citrix connection, it would ease the whole update process.
(On further option which I consider is to use bazaar to push our updates to the sftp server and then pull the updates from there, but unfortunately there is no working svn plugin for bazaar available [on windows])
Okay, not wanting this to remain unsolved, I posted the following on the usenet in alt.os.citrix:
G'day everyone
Someone asked me this question. I haven't a clue. Any ideas?
"the connection I have is PC -> Citrix Access Gateway -> actual Server. My question is, if it is possible to establish a ssh connection from my PC to the actual Server."
The response I got from a Catherine Jefferson was:
Should be. I do this all the time using an Access Gateway VPN, then ssh to servers inside the company LAN.
What version of the Access Gateway is this user running? I work for Citrix, might be able to get a more specific answer for him or her.
So may I suggest you hook into alt.os.citrix (probably via Google Groups if you don't have an NNTP tool) and buy into the conversation.
--Bruce
I do this a lot. The tunnel is like:
ssh -nvCXAN -L 1494:10.0.2.39:1494 www.starshipping.com &
Then, you need an ICA file that points to localhost.
[WFClient]
Version=2
[ApplicationServers]
Connection To Citrix Server=
[Connection To Citrix Server]
WinStationDriver=ICA 3.0
TransportDriver=TCP/IP
ClientAudio=Off
DesiredColor=8
Username=yourusername
Domain=yourdomain
Password=xxxxxxxxx ; has to be encrypted. I pulled from another ICA file generated internally
ScreenPercent=97
TWIMode=OFF
Address=localhost
This all worked very fine on OSX until Citrix gave out a new version of the Citrix client which is now called the Citrix Online Plugin. Haven't been able to get it to work since then. Meanwhile, our VPN has been working fine, so haven't worried too much about it.
Citrix over SSH, How to Create a Key Pair for SSH Authentication Using PuTTYgen, Terminals. It seems that the answers are "out there" but not readily found. That was just five minutes in Google. HTH.