*** nowen (~nowen@99-174-92-191.lightspeed.tukrga.sbcglobal.net) has joined #wikid | 13:50 | |
*** joevano (~joevano@bzflag/developer/JoeVano) has joined #wikid | 15:29 | |
*** Troy__ (329b9bb1@gateway/web/freenode/ip.50.155.155.177) has joined #wikid | 15:31 | |
Troy__ | Hi Nick.. good morning | 15:34 |
---|---|---|
nowen | good mornign | 15:34 |
Troy__ | quick question about replication | 15:34 |
nowen | ok | 15:34 |
Troy__ | we need to reboot the slave server in order to add some new volume space | 15:34 |
nowen | ok | 15:34 |
Troy__ | will master - slave replication be broken if the wikid slave service goes down for a few minutes while rebooting? | 15:35 |
nowen | you may loose data in the interim. | 15:35 |
Troy__ | in other words, would it be better to take down the primary and slave, restart slave, sync and start primary again? | 15:36 |
nowen | if maintaining the data is key, then yes. | 15:36 |
Troy__ | we are not concerned about losing the few transactions during the few minutes of downtime | 15:36 |
Troy__ | ok | 15:36 |
nowen | I can run some tests here | 15:36 |
Troy__ | just more concerned we would break the replication once the slave is back online | 15:37 |
Troy__ | i guess we could just check the timestamps after they are back | 15:37 |
nowen | how is the delay b/t the two servers? | 15:37 |
Troy__ | haven't checked it recently.. i will check now and let you know | 15:40 |
nowen | Troy__: I just rebooted my secondary test server. it killed replication and it didn't come back until I restarted the primary. | 15:49 |
nowen | once I did that, the two dbs matched b/c the start command syncs | 15:50 |
nowen | so, you will most likely have less downtime if you do it that way | 15:50 |
Troy__ | ok .. good to know.. so I wouldn't have to run the wikidctl sync to sync the db? | 15:54 |
Troy__ | btw, the timestamp different is about 3-4 seconds right now | 15:54 |
Troy__ | i'm thinking I could just leave the slave down.. stop the primary. run the db sync while both are down.. start slave, then start the primary | 15:55 |
Troy__ | sorry.. i just read your statement again | 15:57 |
Troy__ | so the start does sync the db again | 15:57 |
Troy__ | that was not my understanding.. i thought you had to do the sync while they are offline then start slave, master before they would sync | 15:58 |
*** AccentureDan has quit (Quit: Page closed) | 15:58 | |
*** AccentureDan (0cfa9442@gateway/web/freenode/ip.12.250.148.66) has joined #wikid | 15:58 | |
AccentureDan | hey Nick | 15:58 |
AccentureDan | sorry been working on environment buildouts | 15:58 |
AccentureDan | i did not see your comments | 15:58 |
AccentureDan | do you have those handy by chance? | 15:58 |
nowen | yeah | 16:04 |
nowen | I need some clarification | 16:04 |
nowen | do you want the WiKID server to listen on a different port? | 16:05 |
AccentureDan | surely | 16:05 |
AccentureDan | hmmmm | 16:05 |
nowen | or the tokens to send to a differnt port? | 16:05 |
AccentureDan | that is part of it | 16:05 |
nowen | because we can't do the latter | 16:05 |
AccentureDan | so ideally this is what we would want | 16:05 |
AccentureDan | we want to have the IP address that is listening for one-time password requests to be NATd to an external facing IP address, but have that IP address listening on a different port instead of 443 | 16:06 |
AccentureDan | can that be done? | 16:06 |
AccentureDan | like sort of a "proxy" | 16:06 |
AccentureDan | or maybe have a proxy server service requests, then forward them on to port 443 | 16:06 |
AccentureDan | so have port 60000 listening on the internet for requests, but forward them to port 443 on the WiKID server internally | 16:07 |
AccentureDan | management doesnt feel comfortable having port 443 exposed to the outside world | 16:07 |
nowen | so, OTP requests come in to external IP. They hit a proxy server and are switched from port 80 (not 443) to 8080, say, and sent to the WiKID server? | 16:07 |
AccentureDan | surely there we go | 16:07 |
nowen | This is easily doable. and similar to Troy__'s set up, I believe | 16:08 |
AccentureDan | if we cant change the port WiKID listens on, maybe we can proxy it | 16:08 |
AccentureDan | awesome, do you have any white papers on how to take care of this | 16:08 |
nowen | Can you setup an apache server to do the proxying? or what? | 16:08 |
AccentureDan | last hurdle, just have to do this and test it, then one last design meeting, then implementation (licensing is in the works currently) | 16:08 |
nowen | I don't have a doc on it. I worry it would create more problems for many people ;-) | 16:10 |
nowen | we use a rewrite rule on apache for our demo server: RewriteRule ^/wikid/(.*) http://localhost:8090/wikid/$1 [P] | 16:11 |
nowen | the in /opt/WiKID/tomcat/conf/server.xml, we change port 80 to 8090 | 16:12 |
nowen | <Connector port="8090" protocol="HTTP/1.1" | 16:12 |
nowen | connectionTimeout="20000" | 16:12 |
nowen | redirectPort="443" /> | 16:12 |
nowen | note that all token requests will go to the URL ../wikid/ | 16:13 |
AccentureDan | sorry im back here | 16:18 |
AccentureDan | ahhhh okay | 16:18 |
AccentureDan | lemme go ahead adn try this here | 16:18 |
nowen | we use a rewrite rule, but you might have to use a proxy rule | 16:19 |
AccentureDan | yeaaaaaa assuming there are walkthroughs about this on google? hahahahaha | 16:19 |
AccentureDan | not really an apache guy, more IIS | 16:19 |
AccentureDan | gonna have to look this up | 16:19 |
nowen | me too, really | 16:20 |
nowen | http://stackoverflow.com/questions/1162375/apache-port-proxy seems like a good start | 16:21 |
AccentureDan | gonna be trial and error, but if i can get it to do that in this test environment i should be able to match it | 16:21 |
AccentureDan | gonna check that one out | 16:22 |
AccentureDan | do we just utilize apache from linux or one that comes with WiKID? | 16:22 |
nowen | from linux, esp since there isn't one with wikid, | 16:27 |
nowen | you're putting this on a separate box, right? | 16:27 |
AccentureDan | well the way it would work, like the way we have things set up now | 16:28 |
AccentureDan | we have a Windows routing and remote access server servicing requests for remote access, with NPS of course...that box has an external facing network adapter and internal facing network adapter | 16:29 |
nowen | ideally, I think what you would do is have the proxy in the DMZ and WiKID on the inside | 16:29 |
AccentureDan | with an internal IP NATd to an external itnernet address | 16:29 |
nowen | oh - can it do the proxy? | 16:29 |
AccentureDan | yup that is the plan | 16:29 |
nowen | then no need for apache? | 16:29 |
AccentureDan | the VPN box in the DMZ will listen on a certain port, lets say 60000 | 16:29 |
AccentureDan | and forward all requests to the WiKID server internally, which wont be in the DMZ | 16:29 |
nowen | listening on 60000 will get boring because the token requests will come in on 80 | 16:30 |
AccentureDan | all i want to do is take this address on the windows box that is listening on port 60000 and forward all those requests on to the WiKID server | 16:30 |
AccentureDan | well any port, that is just arbitrary | 16:30 |
nowen | again, we can't rewrite the port that all our tokens use | 16:30 |
AccentureDan | can't you set it up in the token to forward all token requests to a proxy? | 16:30 |
AccentureDan | so if i put the external address of the VPN box with port 60000 in the token client, wouldnt it send all requests to that port listed? | 16:31 |
AccentureDan | sorry if im not making sense haha | 16:31 |
nowen | yeah, you lost me | 16:31 |
nowen | try it and see | 16:31 |
nowen | the PC tokens support proxies. smart phone tokens do not | 16:32 |
AccentureDan | LOL | 16:32 |
AccentureDan | ahhh okay, well not a big deal most will only be using PC token clients | 16:32 |
AccentureDan | so lets throw out the smart phone idea for now | 16:32 |
nowen | also, many ISPs will not allow traffic on arbitrary ports | 16:32 |
AccentureDan | we can force users to use just the PC token client | 16:32 |
AccentureDan | hmmmmmmm | 16:32 |
nowen | bad idea, I think | 16:32 |
AccentureDan | okay lets walk through this | 16:32 |
AccentureDan | keeping everything stock | 16:32 |
AccentureDan | i want my wikid server internal, not on the DMZ | 16:33 |
AccentureDan | i dont want it facing the internet on port 80 | 16:33 |
AccentureDan | how do clients request tokens? | 16:33 |
nowen | tokens >> external IP port 80 >> VPN >> Proxy server >> port 8080 internal IP >> WiKID | 16:34 |
nowen | WiKID >> port 8080 >> proxy server >> port 80 >> VPN >> token client | 16:34 |
AccentureDan | okay im lost LOL | 16:35 |
AccentureDan | sorry about this | 16:35 |
AccentureDan | trying to match it to my diagram | 16:35 |
nowen | np | 16:35 |
AccentureDan | so the token client on someone's PC requests tokens on port 80 | 16:35 |
nowen | correct | 16:36 |
AccentureDan | they are requesting it from the WiKID server, correct? | 16:36 |
nowen | yes | 16:36 |
AccentureDan | so the WiKID server has to be facing the Internet, correct? | 16:36 |
nowen | correct, or have a proxy that will pass it the data | 16:37 |
AccentureDan | okay so lets go with the proxy for now | 16:37 |
AccentureDan | where would i insert the proxy? | 16:37 |
AccentureDan | meaning, where would this guy live and how would he take in the requests? | 16:37 |
nowen | between the external connection and WiKID | 16:37 |
AccentureDan | so have the proxy sitting in the dmz, then forwarding requests on to the internal wikid server? | 16:38 |
nowen | yes | 16:38 |
AccentureDan | okay awesome this is what i want | 16:38 |
AccentureDan | sure we have been on the same page im just messing up my words lmao | 16:38 |
AccentureDan | so the domain identifier for WiKID, the one token clients use | 16:38 |
nowen | it would take the port 80 requests for the external IP and convert them to 8080 requests on the internal IP | 16:38 |
nowen | the domain id is based on the external IP | 16:38 |
AccentureDan | that would be set up as the proxy address right? | 16:38 |
AccentureDan | i see | 16:38 |
nowen | the proxy server doesn't know anything about the domain id, it just passes the traffic from one ip:port to another ip:port | 16:39 |
nowen | kind of like how the wikid server doesn't really have the external IP, it just responds | 16:40 |
nowen | so, you could have the VPN take any request for the external ip on port 80 and pass it to your Windows routing and remote access server, that server would send it to the WiKID server changing the port | 16:44 |
AccentureDan | sorry back | 16:45 |
AccentureDan | okay i smell what your steppin in,. almost there | 16:45 |
AccentureDan | so with my VPN box, listening on an external internet IP | 16:45 |
AccentureDan | well first | 16:45 |
AccentureDan | the WiKID server is still going to service requests on 80, got that | 16:47 |
AccentureDan | the server code that i set up, that is where my question lies | 16:47 |
nowen | hmm | 16:49 |
AccentureDan | more of a design question | 16:49 |
AccentureDan | how do i put this | 16:49 |
AccentureDan | i currently have my test WiKID server with two network adapters...one externally facing (the internet theoretically) and one facing internal | 16:49 |
AccentureDan | so like the WiKID server would be servicing requests from the Internet | 16:50 |
AccentureDan | now, we will be using proxy | 16:50 |
AccentureDan | will I still need two network addresses (and adapters)? | 16:50 |
nowen | not really | 16:50 |
AccentureDan | for the WiKID server that is | 16:50 |
nowen | when the token requests an OTP, it looks like: http://888.888.888.888/wikid/servlet/com.wikidsystems.server.WikidCode3AES?S=888888888888&D=5871062969131179567&withTTL=1&CT=1 | 16:51 |
AccentureDan | weird address | 16:51 |
nowen | see - it has an IP address (sort of) the 888.888.888.888 | 16:51 |
nowen | and the domain ID | 16:51 |
nowen | it is a dns-based domain | 16:51 |
nowen | so if the IP address gets converted the WiKID server doesn't care | 16:52 |
AccentureDan | come to L.A. and help me build this :-P | 16:52 |
nowen | the request is http://888888888888.wikidsystems.net/wikid/servlet/com.wikidsystems.server.WikidCode3AES?S=888888888888&D=5871062969131179567&withTTL=1&CT=1 | 16:52 |
AccentureDan | i see i see | 16:52 |
nowen | I don't like flying and I don't like touching other peoples servers ;-) | 16:52 |
AccentureDan | LMAO | 16:53 |
AccentureDan | this has been a long process but almost done | 16:53 |
AccentureDan | just one last design. almost there man | 16:53 |
AccentureDan | let me know if this is right or wrong | 16:53 |
AccentureDan | my VPN box will also be my proxy for the WiKID requests, which will forward requests from a different listening port to port 80 internally to my WiKID server | 16:54 |
nowen | yeah, we are still not there | 16:54 |
AccentureDan | yup | 16:54 |
AccentureDan | my main question is, if i have one IP address for my WiKID server (the server code), lets say 10.0.0.1 | 16:54 |
nowen | "my VPN box will also be my proxy for the WiKID requests, which will forward requests from port 80 internally to my WiKID server (on whatever port you want) | 16:55 |
AccentureDan | okay, question | 16:55 |
AccentureDan | which port is the proxy listening on? | 16:55 |
nowen | 80 | 16:55 |
AccentureDan | okay so 80 would still need to be exposed to the internet | 16:56 |
nowen | yes | 16:56 |
AccentureDan | i know they wont like that...help me spin doctor this clean | 16:56 |
AccentureDan | so even thoug hit is listening on port 80, the requests will be sent on a different port to my wikid server | 16:56 |
nowen | if you want that | 16:56 |
AccentureDan | and we cant set the proxy to be listening on a different port, or it just doesnt matter? | 16:57 |
nowen | there's no security added by having it on a different port and some maintenance hassle | 16:57 |
nowen | a port is a port | 16:57 |
nowen | Can you set your VPN to reject every request that doesn't go to /wikid ? | 16:58 |
AccentureDan | completely agree...they were talking about having it listening on a different port because they dont want people port scanning and finding something common open | 16:58 |
AccentureDan | that was their reasoning | 16:58 |
AccentureDan | good question, not entirely sure | 16:58 |
AccentureDan | first time working with RRAS | 16:58 |
AccentureDan | im sure it can be done | 16:58 |
AccentureDan | i can harden the server via Firewall | 16:58 |
AccentureDan | right now our box can only receive L2TP over IPSec requests | 16:58 |
AccentureDan | 80 isnt open | 16:58 |
AccentureDan | it's hardened even in the DMZ | 16:59 |
AccentureDan | they are just concerned about opening up a common port | 16:59 |
nowen | sure | 16:59 |
AccentureDan | i know this may be asking alot of you, but would you be open to a conference call discussion? I know it may not be your thing | 16:59 |
AccentureDan | but just to discuss things with my network engineers and supervisor? | 17:00 |
nowen | maybe | 17:00 |
AccentureDan | if we have ot listen on port 80, it would sound better coming from someone like you lmao | 17:00 |
AccentureDan | im sure they have questions and you are knowledgeable, if you want to answer | 17:01 |
AccentureDan | LOL | 17:01 |
AccentureDan | if not if you know someone else that is perfectly fine | 17:01 |
nowen | but first you need to tell me what your firewall can do | 17:01 |
AccentureDan | i just know if i go back and say 80 has to be opened they will want to know why and how we can protect things...not sure i can answer it from the WiKID perspective | 17:01 |
AccentureDan | well our design is like this | 17:01 |
nowen | because it is the only port guaranteed to work | 17:02 |
AccentureDan | we have our DMZ, a firewall in front of it, then a secure internet gateway managed by Verizon | 17:02 |
AccentureDan | brb man | 17:02 |
AccentureDan | one sec | 17:02 |
AccentureDan | okay im back | 17:04 |
AccentureDan | i getcha | 17:04 |
AccentureDan | its not a problem, we just need to make sure the others understand | 17:04 |
AccentureDan | it's a network with client data and all that jazz, client data protection is high on their list, i know why they are concnerned | 17:05 |
AccentureDan | im sure the network engineers would be better able to answer port questions as well...if you have any specifics needed | 17:06 |
AccentureDan | hey gonna switch to my laptop. gonna drop off this IRC real quick | 17:07 |
nowen | ok | 17:07 |
AccentureDan | nvm | 17:07 |
AccentureDan | essentially the proxy is a bit reversed...we are taking traffic on port 80 and switching it to another port that WiKID is listening on...but we can't do the opposite and have the proxy listening on a different port, and send to a port like 80 on the WiKID server | 17:09 |
nowen | correct | 17:10 |
AccentureDan | so question | 17:10 |
AccentureDan | i know a bunch of people have this stuff set up | 17:10 |
AccentureDan | do you find it a security threat to have 80 exposed to the internet | 17:10 |
nowen | no. there is no security from obscurity. | 17:11 |
AccentureDan | i just want to relate what we are trying to do versus what others have | 17:11 |
AccentureDan | i see | 17:11 |
nowen | if you move ssh from port 22 to something else, what you get is fewer logs to review | 17:11 |
nowen | nmap will scan any port | 17:11 |
AccentureDan | true, no matter what port if it is open people can find it | 17:11 |
nowen | so, have 80 open, but appear to not be listening unless the request goes to /wikid | 17:12 |
AccentureDan | how would i go about doing that? | 17:13 |
AccentureDan | so only listen for requests going to that | 17:13 |
nowen | depends on your vpn or proxy | 17:13 |
AccentureDan | i guess i need ot understand more about what the client is asking when it sends a request over the Internet | 17:14 |
AccentureDan | i know it is asking for the server code | 17:14 |
nowen | you can run the PC token in debug mode to see it all | 17:14 |
AccentureDan | and the server code has to be facing the Internet since you can't request OTPs from an internal address | 17:14 |
nowen | it has to be routable | 17:14 |
AccentureDan | well it would be NATd no matter what | 17:15 |
AccentureDan | they just want the WiKID server internal and servicing only internal requests | 17:15 |
nowen | thus the proxy | 17:16 |
nowen | defense in depth | 17:16 |
AccentureDan | okay lets do this | 17:16 |
nowen | the VPN will be serving info to the outside right? | 17:16 |
AccentureDan | so on the VPN box sits RRAS listening JUST for L2TP over IPSec connections | 17:16 |
AccentureDan | in order to service 80 requests there needs to be IIS | 17:16 |
AccentureDan | let me check this out | 17:16 |
AccentureDan | okay good IIS is up | 17:17 |
AccentureDan | so when a user requests a OTP from the token client, they are going to my external facing WiKID server IP address | 17:17 |
AccentureDan | that would need to change in order to redirect the request to the VPN box, correct? | 17:18 |
nowen | what would need to change? | 17:18 |
AccentureDan | if we are going to use the VPN box as the proxy, wouldnt the address the token client is requesting an OTP from have to be the VPN server's IP address? | 17:19 |
nowen | does the VPN not currently control the WiKID's IP? | 17:19 |
AccentureDan | i know im thinking about this wrong | 17:19 |
nowen | do you actually have it setup externally now? | 17:20 |
AccentureDan | the VPN box is just listening for requests for remote access...so once the user requests the one-time password and gets it, it would then accept the token and username | 17:20 |
AccentureDan | well in the test environment, it is internal completed but i have it set up mimicking external setup | 17:20 |
AccentureDan | would it be easier if i sent you a diagram with all this stuff? hahahaha | 17:20 |
AccentureDan | i know im asking you to draw this in your head | 17:21 |
AccentureDan | not fair to you | 17:21 |
nowen | you can if you like | 17:21 |
nowen | but let me ask you this: | 17:21 |
AccentureDan | if it would hlep you i could | 17:21 |
nowen | did you set up an external IP that does not go through your VPN? | 17:21 |
AccentureDan | yes, the WiKID server is set up to listen on the Internet with it's own IP, and has another Internal address to communicate with the domain controller via NPS | 17:22 |
AccentureDan | that external IP is theoretically listenining on the "internet" for one-time passcode requests | 17:22 |
AccentureDan | should it be different? | 17:22 |
nowen | I'm just surprised that you can do that if you're companies worried about having port 80 open | 17:22 |
AccentureDan | well it was for test purposes | 17:23 |
AccentureDan | it was how it worked originally | 17:23 |
AccentureDan | i can change that | 17:23 |
AccentureDan | again just trying to get the design down | 17:23 |
nowen | well, so, back to the question: yes, you would change it to an IP that the external VPN controlled | 17:23 |
AccentureDan | fantastic, so this answer a big question | 17:24 |
nowen | bonus: if the network admin says that port 80 shouldn't be open, tell him his vpn sucks | 17:24 |
AccentureDan | so the wikid server would have one internal IP address to service those internal requests to the domain controller | 17:24 |
nowen | define 'domain controller' | 17:25 |
AccentureDan | and then just assign the address "external" of the WiKID server to an address that can talk to the VPN box | 17:25 |
AccentureDan | nvm woops | 17:26 |
AccentureDan | it doesnt use that to talk to the DC | 17:26 |
AccentureDan | it uses that to talk to the VPN box | 17:26 |
AccentureDan | woops | 17:26 |
AccentureDan | that is used to receive the OTP from the VPN box | 17:26 |
AccentureDan | so basically just get rid of the external adapter on the wikid server | 17:27 |
nowen | sure, or you can give it an internal ip | 17:27 |
AccentureDan | the "internal" adapter or whatever you want to call it is already able to communicate with the VPN box | 17:27 |
AccentureDan | so here is the question | 17:28 |
AccentureDan | The VPN box has one IP address set to listen just for VPN connection requests...so that address would need port 80 open in order to service the requests of the wikid server | 17:29 |
nowen | sounds right | 17:31 |
AccentureDan | so the token client on the PC would request tokens from port 80 on that external IP address of the VPN box | 17:31 |
AccentureDan | and get sent to the WiKID server for processing | 17:32 |
nowen | yes | 17:32 |
AccentureDan | awesome got this now | 17:32 |
AccentureDan | so the wikid server needs one adapter, an internal IP address that is on the same subnet as the NATd IP of the VPN box | 17:32 |
nowen | at least | 17:33 |
AccentureDan | gotcha | 17:33 |
AccentureDan | so to the wikid server | 17:33 |
AccentureDan | that guy is going to service requests on an Internal IP address, let's just say on port 80 for now to get it working | 17:33 |
AccentureDan | so that port will service one-time password requests | 17:34 |
AccentureDan | the same IP address can be used to communicate with VPN box via NPS, or we could create another adapter to service those requests...doesnt make much sense though | 17:34 |
nowen | just a question of how you want to set up your network | 17:35 |
AccentureDan | yup | 17:35 |
AccentureDan | we could create a network for WiKID on it's own to complete segregate it but that is a network engineer decision | 17:35 |
AccentureDan | sorry thinking out loud | 17:38 |
AccentureDan | this is a better design, consolidate a little | 17:38 |
nowen | sure, keep it simple | 17:38 |
AccentureDan | let me make some changes and see how this works | 17:38 |
AccentureDan | brb brotha | 17:38 |
nowen | ok | 17:38 |
AccentureDan | so if i set the IP address of the WiKID server to an internal address, and it is on the same subnet as the IP address of the VPN server, how would users communicate with it outside the network? | 17:43 |
nowen | the VPN will do NAT, correct? | 17:43 |
AccentureDan | or would the IP address of the server code have to be the same as the IP address of the external VPN? | 17:43 |
AccentureDan | yup | 17:44 |
AccentureDan | well, the address of the VPN is NATd | 17:44 |
nowen | the domain ID is based on the external IP | 17:44 |
AccentureDan | we dont have NAT set up for the VPN to do, but we can | 17:44 |
AccentureDan | okay thought so | 17:44 |
AccentureDan | let me do that | 17:44 |
AccentureDan | okay got it all set up | 17:49 |
AccentureDan | so when i go to register for the domain on my token client | 17:49 |
nowen | ? | 17:52 |
AccentureDan | sorry | 17:52 |
AccentureDan | back to that, when i try to register on the token client, and i enter the external IP address of the VPN box, it cant find the domain configuration | 17:53 |
AccentureDan | so i assume I need to forward requests on port 80 to the WiKID server | 17:53 |
AccentureDan | correct? | 17:53 |
nowen | yes | 17:53 |
AccentureDan | okay is there a specific address it is listening on or just the ip address? | 17:54 |
AccentureDan | since 80 is already listening | 17:54 |
nowen | did you create a new domain for the new IP address? | 17:54 |
AccentureDan | yup | 17:55 |
AccentureDan | it is the external IP address of the VPN box | 17:55 |
nowen | run 'tcpdump port 80' on the WiKID server and try to register the domain | 17:55 |
AccentureDan | gotcha one sec | 17:55 |
AccentureDan | okay think i know what it is | 17:58 |
AccentureDan | i have two network adapters on my jump box | 17:58 |
AccentureDan | one is internal and one is external | 17:58 |
AccentureDan | i set it up to the wrong address | 17:58 |
AccentureDan | one sec | 17:58 |
nowen | AccentureDan: I may need to go run an errand. what is your status? | 18:30 |
nowen | ok - definitely headed out. | 18:46 |
nowen | AccentureDan: I should be back around 3:45 EST. | 18:47 |
*** nowen has quit (Quit: Leaving.) | 18:47 | |
*** lowtax (~lowtax@gateway/tor-sasl/lowtax) has joined #wikid | 18:54 | |
lowtax | hello, getting a blank page on intermediate ca | 18:54 |
lowtax | this software seems extremely bad | 19:01 |
*** lowtax has parted #wikid ("Leaving") | 19:15 | |
*** happy_nodes (~happy_nod@5353BF9D.cm-6-4c.dynamic.ziggo.nl) has joined #wikid | 19:27 | |
happy_nodes | I am trying to create Intermmediate CA. But It is showing blank page | 19:40 |
happy_nodes | I installed it using VM, did setup and started the service | 19:41 |
*** Troy__ has quit (Ping timeout: 250 seconds) | 20:09 | |
*** nowen (~nowen@99-174-92-191.lightspeed.tukrga.sbcglobal.net) has joined #wikid | 20:41 | |
nowen | back | 20:42 |
nowen | happy_nodes: what page is showing you the blank screen? | 20:43 |
nowen | last cert CSR submitted was issued at 2:07. | 20:45 |
nowen | happy_nodes: it works for me | 20:56 |
happy_nodes | Configuration -> Create an Intermmediate CA | 21:38 |
happy_nodes | This page does not show anything | 21:38 |
nowen | happy_nodes: any errors in the logs? | 21:39 |
nowen | happy_nodes: what version is this? | 21:40 |
happy_nodes | This is the one I see : psql:/opt/WiKID/conf/database/migrations/cumulative.sql:972: NOTICE: Exception in dbmigrate11. This migration may have already been performed | 21:41 |
nowen | is that in the WiKIDAdmin logs? | 21:42 |
happy_nodes | I found it in cumulative.log | 21:46 |
happy_nodes | in /opt/WiKID/log | 21:46 |
nowen | just look in the log link in the WiKIDADmin UI | 21:46 |
happy_nodes | I am new to wikid | 21:46 |
happy_nodes | ok | 21:47 |
nowen | np | 21:47 |
happy_nodes | There is nothing in logs | 21:48 |
nowen | hmm | 21:48 |
nowen | what version is this? | 21:48 |
happy_nodes | Let me check | 21:50 |
happy_nodes | 3.1.22 | 21:52 |
happy_nodes | No It is not this one | 21:53 |
happy_nodes | The one I have installed is wikid-enterprise-3.5.0-b1359-install.iso | 21:54 |
nowen | ok | 21:54 |
happy_nodes | and it comes wth Centos 6 | 21:55 |
happy_nodes | sorry Centos 5 | 21:55 |
happy_nodes | Do you have the one with Centos 6 | 21:55 |
nowen | not yet | 21:55 |
happy_nodes | ok | 21:55 |
nowen | how long ago did you download this? | 21:56 |
happy_nodes | Its been long time | 21:56 |
nowen | ok | 21:56 |
happy_nodes | It was on our repository | 21:56 |
happy_nodes | so, I do not know since how long we have it | 21:57 |
nowen | are you an existing customer? | 21:57 |
nowen | you mean the RPMs were in your repo? | 21:57 |
happy_nodes | Yes, We are existing customer | 21:57 |
happy_nodes | vmimage is on our datastore | 21:57 |
happy_nodes | one of the wikid server died | 21:58 |
nowen | who are you with? | 21:58 |
happy_nodes | so, I am reinstalling it | 21:58 |
happy_nodes | workforcesoftware | 21:58 |
nowen | ok | 21:59 |
nowen | let's try to update via rpm | 21:59 |
nowen | i'll give you the url to download it | 22:00 |
happy_nodes | ok | 22:00 |
nowen | http://wikidsystems-dl.com/wikid-server-enterprise-3.5.0.b1472-1.noarch.rpm | 22:00 |
happy_nodes | Can I try it on other server. We basically want to test it on Centos 6 Server | 22:01 |
happy_nodes | i have a test server ready | 22:01 |
nowen | yes | 22:01 |
happy_nodes | IOk | 22:01 |
nowen | is it 32 or 64 bit? | 22:01 |
happy_nodes | 64 bit | 22:02 |
nowen | ok, you will also need the utilities rpm | 22:02 |
nowen | http://wikidsystems-dl.com/wikid-utilities-3.4.3-1.x86_64.rpm | 22:03 |
happy_nodes | ok | 22:03 |
nowen | and then follow these: http://www.wikidsystems.com/support/wikid-support-center/installation-how-tos/how-to-install-the-wikid-enterprise-rpms | 22:04 |
nowen | note that Sun's jdk may be a bit faster than openjdk, but it's a pain to install | 22:04 |
nowen | not sure what's going on with the old iso | 22:05 |
happy_nodes | It is a new machine | 22:05 |
happy_nodes | I have java installed | 22:06 |
*** happy_nodes has quit (Quit: HydraIRC -> http://www.hydrairc.com <- Like it? Visit #hydrairc on EFNet) | 22:24 | |
*** nowen has quit (Quit: Leaving.) | 23:06 |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!