Here is the full error:

PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[08004] SQLConnect: 1033 [unixODBC][Oracle][ODBC][Ora]ORA-01033: ORACLE initialization or shutdown in progress\nProcess ID: 0\nSession ID: 0 Serial number: 0\n'

I am using unixODBC to connect to an oracle 11g database. The database is up and functioning as proof by:

select open_mode from v$database;

returns

open_mode
-----------------
read write

The web application of the service is completely functional as well.

and finally, I can run:

isql -v [odbc store] [user] [password]

and query the database just fine that way.

So I am truly at a loss as to why I cannot connect through the ODBC to get what I need. Everything I've read has stated that I should follow a procedure similar to this: link to solve similar problems

Thanks for any input. I'm really at my wits end here.

I would like an external client (4.3.2.1) to use our proxy (9.9.9.9) which forwards traffic to our firewall (8.8.8.8) which then forwards the traffic back to our client (4.3.2.1).

So I'm curious if:

1. This is possible
2. squid the best choice
3. There a quick and dirty guide available
4. The proxy needs to sit in front of or behind the firewall

I've done quite a bit of research and see a proxy used in various ways, but not in the way that I want to use it.

Here is the set up I am trying to accomplish

So, what I'm trying to accomplish is: a user goes to 10.0.0.1 it passes it to whichever loadbalancer is managing the requests. I then want varnish actually to handle the request.

Here is my ha.cf file:

debug                           3
debugfile                       /var/log/ha-debug
logfile                         /var/log/ha-log
bcast                           eth0
keepalive                       2
warntime                        5
deadtime                        15
initdead                        30
udpport                         694
udp                             eth0
auto_failback                   yes
node                            loadb1
node                            loadb2

*This is the same on loadb2. Also I have the debugging enable for testing purposes. It will be removed when its production ready.

Here is haresources

loadb1 IPaddr::10.0.11.200/32 varnishd

*Again, same on loadb2 (I have also tried to make it so that heartbeat doesn't manage anything other than the IP; so no "varnishd" at the end in the haresources)

My varnish config is as follows:

 backend server1 {
.host = "10.5.0.111";
.probe = {
.url = "/";
.interval = 5s;
.timeout = 1 s;
.window = 5;
.threshold = 3;
}
}
backend server2 {
.host = "10.5.0.112";
.probe = {
.url = "/";
.interval = 5s;
.timeout = 1 s;
.window = 5;
.threshold = 3;
}
}

director example_director random {
{
.backend = server1;
.weight = 2;
}
{
.backend = server2;
.weight = 1;
}
}

sub vcl_recv {
if (req.http.host ~ "^(www.)?bps101.net$") {
set req.backend = example_director;
}
}

I have my heartbeat working fine. The ip 10.0.0.1 is fully pingable. But when I got to 10.0.0.1 in a browser I get a connection reset. (nothing is listening on port 80). I know the varnish config works. I know the heartbeat config works. I just cannot get them to work together. Does anyone have any suggestions or ideas? I would greatly appreciate any advice, direction, etc that anyone can provide. Thanks.

So I have heartbeat installed, I followed a config guide where I literally changed the IP's of the guide and it's not working as it should :(.

The reason the eth numbers are obviously different. I don't think that should have any effect on the resource handling though. I used uname -n for the node names. I have placed their ip's in the /etc/hosts file so they know about each other.

There is nothing suspicious in the logs. Also Apache is set to listen on any interface available.

I cannot ping or reach the shared resource at all. Any Ideas?

Here are my configs on my two servers that are running heartbeat. They are aptly named loadb1 (192.168.1.101) and loadb2 (192.168.1.102) and their shared resource: 192.168.1.100.

Loadb1's configs are:

ha.cf

logfile /var/log/ha-log
bcast eth0
keepalive 2
warntime 10
deadtime 30
initdead 120
udpport 694
udp eth0
auto_failback yes
node loadb1
node loadb2
#uuidfrom nodename
#respawn hacluster /usr/lib/heartbeat/ipfail

haresources

loadb1 IPaddr::192.168.1.100 httpd

authkeys (which is set to 600)

auth 2
2 crc

Loadb2's configs are:

ha.cf

logfile /var/log/ha-log
bcast eth1
keepalive 2
warntime 10
deadtime 30
initdead 120
udpport 694
udp eth1
auto_failback yes
node loadb1
node loadb2
#uuidfrom nodename
#respawn hacluster /usr/lib/heartbeat/ipfail

haresources

loadb1 IPaddr::192.168.1.100 httpd

authkeys (which is set to 600)

auth 2
2 crc

When I run "service heartbeat status", I get:

heartbeat OK [pid xxxx et al] is running on loadb[x] [loadb[x]]...

depending on which server I'm on it will read loadb1 or loadb2

We are currently putting in place a freeradius server that uses certificates to authenticate via a wireless connection. We have this working for 802.1x but Novell's client for Windows 7 breaks the 802.1x protocol. So we have to have the certificate based authentication.

I have a test domain set up and running, I can get regular internal/external authentication to happen. Once I implement the certs is when things start going crazy. I have attached my radius -X output (at least the portions of it where it tries to instantiate the EAP module. I have googled around for answers but really haven't found anything. Any help would be greatly appreciated. Thank you.

Module: Instantiating eap
  eap {
        default_eap_type = "eap"
        timer_expire = 60
        ignore_unknown_eap_types = no
        cisco_accounting_username_bug = no
        max_sessions = 4096
  }

 Module: Linked to sub-module rlm_eap_md5
 Module: Instantiating eap-md5
 Module: Linked to sub-module rlm_eap_leap
 Module: Instantiating eap-leap
 Module: Linked to sub-module rlm_eap_gtc
 Module: Instantiating eap-gtc
   gtc {
        challenge = "Password: "
        auth_type = "PAP"
   }
 Module: Linked to sub-module rlm_eap_tls
 Module: Instantiating eap-tls
   tls {
        rsa_key_exchange = no
        dh_key_exchange = yes
        rsa_key_length = 512
        dh_key_length = 512
        verify_depth = 0
        pem_file_type = yes
        private_key_file = "/etc/raddb/certs/server.pem"
        certificate_file = "/etc/raddb/certs/server.pem"
        CA_file = "/etc/raddb/certs/ca.pem"
        private_key_password = "whatever"
        dh_file = "/etc/raddb/certs/dh"
        random_file = "/etc/raddb/certs/random"
        fragment_size = 1024
        include_length = yes
        check_crl = no
        cipher_list = "DEFAULT"
    cache {
        enable = no
        lifetime = 24
        max_entries = 255
    }
   }
 Module: Linked to sub-module rlm_eap_ttls
 Module: Instantiating eap-ttls
   ttls {
        default_eap_type = "mschapv2"
        copy_request_to_tunnel = no
        use_tunneled_reply = no
        virtual_server = "inner-tunnel"
        include_length = yes
   }
 Module: Linked to sub-module rlm_eap_peap
 Module: Instantiating eap-peap
   peap {
        default_eap_type = "mschapv2"
        copy_request_to_tunnel = no
        use_tunneled_reply = no
        proxy_tunneled_request_as_eap = yes
        virtual_server = "inner-tunnel"
   }
 Module: Linked to sub-module rlm_eap_mschapv2
 Module: Instantiating eap-mschapv2
   mschapv2 {
        with_ntdomain_hack = no
   }
rlm_eap: Unknown default EAP type eap
/etc/raddb/eap.conf[17]: Instantiation failed for module "eap"
/etc/raddb/sites-enabled/inner-tunnel[223]: Failed to load module "eap".
/etc/raddb/sites-enabled/inner-tunnel[176]: Errors parsing authenticate section.

We have a sles10 sp2 oes2 sp1 server that is in eDirectory as a replica server. However in our ds ring it is not showing up. It shows up as synched for time but it will not show up in our replica ring. Any ideas?

Does anyone know if there is a way to mount an NSS volume (novell) on server 2003/2007? We obviously need it to maintain user rights and what not. Even a place to start looking (google has nothing that I can find) (and novell, when the TIDs exist they are great, but the chance of them existing is very small...)

Thanks.

edit: we are looking for a migration method.

I am trying to cluster 3 servers to then mount an NSS. I have all 3 configured and ready to roll. The only problem is none of them are apart of any cluster. When I run the: "cluster join" command I get the following:

Joining...
Now a member of
This node is not a member of a cluster

I'm very green to clustering so I don't know exactly what to look for in this case. There is an edirectory object that is labeled "cluster" and it has all 3 servers listed underneath the object.

I have NCS installed and I am assuming configured properly. I have looked in the HA section of yast and insured that all 3 servers are a part of "cluster". iManager throws this error when I try to run cluster manager:

File Protocol error occurred: cannot open the NCS version file on the selected cluster. The Cluster software may not currently be running on this server.

It is all sles oes sp2. Not updated (for authentication reasons).

Any amount of help is greatly appreciated.

We have a wireless network that authenticates via 802.1x free-radius server. We have told the wireless network to authenticate accordingly and it works. However when we have a wired network we have to uncheck the "authenticate to 802.1x" box (In our novell client) and then we can log in fine. Does anyone know a way to allow for seamless decision making when authenticating. We don't want users to have to have to remember to check or uncheck a box based on where they are.

Set-up: XP SP3 Novell 4.91 SP5 Authenicate Via free-radius wirelessly NO 802.1x authentication via wire

Thanks.

We are running Novell 4.91 sp5 with Symantec Endpoint. We are authenticating via 802.1x and when Symantec is running we get an 802.1x Auth Fail. RPC error occurred. Failed to authenticate" We absolve the error by shutting symantec down completely OR logging in locally and then logging out and logging in via network credentials (802.1x).

We called symantec and really didn't get anywhere. We think that the problem could lie in the snap.dll file and the way that it interacts with the NovEap.dll file. But we have no real evidence of this. Any ideas?