AltME groups: search

Today the whole altme.com DNS server went down, so all Altme worlds 
around the globe went down (not exactly like that, but close)

22/9-10:18:36.371-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 300
    type: 'script
    id: 'no-value
    arg1: 'startegy
    arg2: none
    arg3: none
    near: [pick dns-server switch startegy [
            round-robin [first head reverse dns-server]
            random [pick dns-server random length? dns-server]
        ]]
    where: 'on-init-port
] !

this is with dns-server [ 203.96.152.4 230.96.152.12 ] in my httpd.cfg 
globals

In dig.r line 174 should read

			pick dns-server switch strategy [
as there is a typo there.

actually I think line 174 should read

			switch strategy [

and lose the "pick dns-server"

SVN r30 :


FEAT: MTA engine refactored, jobs are split in sub-tasks allowing 
more reliable and cleaner code.
FEAT: Default SMTP delay reduced to 5mn.

FEAT: MTA queue can now be saved on disk when server is restarted 
(persist [mail-queue])

FEAT: added native DNS async wrapper for UniServe (protocols/DNS.r)

FEAT: replaced blocking DNS calls for MX domain resolution by async 
DNS calls.

FEAT: 'on-mx event in DIG protocol now returns a block of all the 
declared MX.

FEAT: now all MX will be tried in right order by the MTA if connexion 
fails.
FEAT: improved SMTP logs by prefixing with a SMTP session ID.

FEAT: upload data in HTTPd limited to 2GB (max supported by integer! 
type)

FEAT: 'email-info? RSP function return data format improved (see 
email.rsp header)

FIX: email.rsp minor bugs fixed and From: field added.
FIX: minor fixes in email.r library.

FIX: now uni-engine's logging level is also set by 'set-verbose function.

Getting this is in the latest Cheyenne when encapped

7-Oct-2009/12:12:03+13:00 : make object! [
    code: 500
    type: 'access
    id: 'cannot-open
    arg1: "/C/Rebol/UniServe/protocols/DNS.r"
    arg2: none
    arg3: none
    near: [do any [get-cache file file]]
    where: 'do-cache
]

Ok.. Chrome has a "prefetch dns" option..  so my demo was caching 
the ip rather than the domain

I've updated the domain to a proper dns record, rather than just 
forwarding.

If you still can't see the demo, turn off "prefetch dns".. temporarily

http://shinyrockets.com/ws2.html

Article regarding chrome dns prefetching

http://tinyurl.com/4adsdd

This is helpful as well.. in the chrome address bar type;
about:dns

I'd ask Terry to write it for Cheyenne... but I suspect that we'll 
never be able to reach it because of dns issues!

Graham, did you shut off the Chrome dns prefetching?

Turning off DNS prefetching is explained here : http://jackkonblog.blogspot.com/2009/03/turn-off-dns-pre-fetching-in-google.html

SVN r62


FEAT: RSP scripts can now set response/buffer to a file! value allowing 
main process to transfer it optimally (see changelog.txt)

FEAT: worker tasks now have a more readable and cleaned-up command 
line.

FIX: fixed a bug with internal UniServe's DNS cache querying preventing 
'open-port from working in some cases.

This last fix was blocking sometimes the builtin MTA to connect to 
DNS or MX servers.

probably a DNS issue... he has changed servers... so the IP surely 
has changed?

First of all you must add DNS A records to point to your IP adress. 
And then setup your server (Cheyenne, Apache, Nginx..) to resolve 
the full subdomain.domain names.

I think you want multiple subdomains, one for each user, and you 
can simplify that by defining one catch-all IP number in DNS. Then 
define all the virtual hosts in Cheyenne. You do have to add every 
subdomain to Cheyenne, but this way you don't have to maintain DNS 
for each

if u want something nicer, multicast dns, and a superfast and well 
thought out control panel, check out dnsmadeeasy.com

What's the oneliner?  Defining the sub domains as DNS A records doesn't 
work ....

Still, I can't make Cheyenne work as non-root user : the HTTP log 
file keeps being written as root:root even if the main Cheyenne process 
is own by a non-root user. The culprit seems to be the REBOL helper 
process, forked by the main one during REBOL internal boot process 
(so before starting to run user code). I found no way to setuid this 
child process (seems forbidden by the OS?), so it keeps being owned 
by root...


Here's my typical test case under linux (Ubuntu 8.04, /enpro 2.7.6, 
latest SVN revision,using [user "dk"] in config file). I'm running 
the test from a root shell to avoid issues of sudo with REBOL binaries 
(RAMBO #4306) :

;--- launching  Cheyenne process  ---
[root-:-dknux]:/mnt/dev/Cheyenne# ./cheyenne &
[1] 20179


;--- notice the root process below (the only one that Cheyenne can't 
setuid( ) ---
[root-:-dknux]:~# ps aux
[...]

dk       20179  0.2  1.3   9028  6716 pts/0    S    22:21   0:00 
./cheyenne

root     20180  0.0  0.1   2360   600 pts/0    S    22:21   0:00 
./cheyenne

dk       20182  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20183  0.0  0.0   2184   236 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20184  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20185  0.0  0.0   2184   232 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20186  0.1  0.9   6264  4968 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20187  0.0  0.0   2184   236 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20188  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20189  0.0  0.0   2184   232 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

;--- no HTTP log file for now ---
[root-:-dknux]:/mnt/dev/Cheyenne# ls -l log/
total 0

;--- I'm sending a request to http://localhost/---
[root-:-dknux]:/mnt/dev/Cheyenne# ls -l log/
total 1
-rw-r--r-- 1 root root 77 2010-09-09 18:19 default-access.log


The log file belongs to root:root, so it must have been generated 
by process 20180. Killing that process prevents Cheyenne from outputing 
any new log file (but Cheyenne keeps serving all requests). I thought 
that the helper process was only used for enabling async dns requests 
when OS doesn't support it natively?...<vent>Like REBOL GC's rules, 
this helper process remains a mystery even after 10 years of reboling...I 
guess these secrets are worth millions of $ to be kept undisclosed 
so far...</vent>

Any ideas?

Yeah, Carl has given different statements about the helper process. 
Years ago he said garbage collector, lately he said async DNS

It's always been DNS -- never was GC.

I'd like to make that side proc an option.  Holger added it for async 
DNS lookup, but a great deal of the time no lookup is being done, 
or sync DNS lookup is just fine.

that was the infamous zombie dns process in older r2 version

About the possible "fixes" that Cheyenne could benefit from, Carl 
added the helper task (for async DNS) deferred boot to workaround 
setuid issues (security improvement when running Cheyenne as not 
root user).

I have Solaris versions with date stamps ( the date I copied them 
to the server ) of 2000, 2001, and 2003.  I think these versions 
were susceptible to creating zombie dns processes

So, I can't even connect to ODBC DNS on windows 2008

Database migration done. Curecode.org domain's IP has been changed 
to point to a new server, so during the DNS propagation time, curecode.org 
will work on both the old and new server (24-48h). Both Curecode 
instances are now pointing to the same database instance on the new 
server. If all goes well, you shouldn't notice anything, nor have 
any downtime. Let me know if there's any issue.

FYI, my DNS hosting company doesn't allow lowering the TTL, so I 
had to resort to such solution to avoid service interruption due 
to DNS propagation. The new IP is a failover address that I can attach 
freely to any of our servers without any delay, so future server 
migration will be easier to handle.

It works from here with Chrome too. It might be an internal Chrome 
prefetching or DNS caching issue.

make-scheme [
	name: 'daytime
	title: "Daytime Protocol"
	awake: func [event /local port] [
		print ["=== Client event:" event/type]
		port: event/port
		switch event/type [
			lookup [
				print "DNS lookup"
				open port
			]
			connect [
				print "connected" 
				read port
			]
			read [
				close port
				return true ; quits the awake
			]
		]
		false
	]
	actor: [
		;open: func [port [port!]][port]
		read: func [
			port [port!] /local con
		][
			con: open rejoin [tcp:// port/spec/host ":13"]
			con/awake: :awake
			wait con
			to-string con/data
		]
	]
]

probe read daytime://time-a.nist.gov

=== Client event: lookup
DNS lookup
=== Client event: connect
connected
=== Client event: read
{
55203 10-01-07 07:51:23 00 0 0 282.6 UTC(NIST) *
}

I've been reading some more of the docs .. and it says that the lookup 
phase in the awake handler is called when the name is resolved with 
a dns lookup .. but that phase is not used when the url uses an ip 
address.  But then I see some demo code using IP addresses ( the 
ping pong server ) where the open port is in the lookup event ...

only if a dns translation is requested

there is a low level dns lookup occuring in the tcp device ...

my R3 need with DNS is to be able to tell if a domain is there or 
was it mistyped, to prevent calamity

rebol []
make-scheme [
	name: 'dns2
	title: "DNS Protocol"
	spec: make system/standard/port-spec-net [port-id: 80]


	awake: funct [event ] [
		print ["=== Client event:" event/type]
		client: event/port
		switch event/type [
			lookup [
				; print "DNS lookup"
				probe query client
				return true
			]
			connect []
		]
	]
	actor: [
		open: func [
			port [port!]
			/local conn
		] [
			if port/state [return port]
			if none? port/spec/host [http-error "Missing host address"]
			; set the port state
			port/state: context [
				state:
				connection:
				error: none
				awake: none ;:port/awake
				close?: no
			]
			; create the tcp port and set it to port/state/connection
			port/state/connection: conn: make port! [
				scheme: 'tcp
				host: port/spec/host
				port-id: port/spec/port-id
				ref: rejoin [tcp:// host ":" port-id]
			]
			conn/awake: :awake
			open conn
			print "port opened ..."
			; return the newly created and open port
			wait conn
			conn
		]
	]
]

open dns2://www.rebol.com

I only wrote an open actor for my dns scheme

Should be enough

make-scheme [
	title: "Dns"
	name: 'dns2
	actor: [
		read: func [port [port!] /con][
			con: open [scheme: 'tcp host: port/spec/host]
			con/awake: func [event][true]
			wait [con 5]  ;*** timeout 5 secs
			attempt [get in query con 'remote-ip]
		]
	]
]
>>read dns2://www.rebol.net
216.240.11.203

Now how to do a reverse dns lookup??

IIRC we need UDP to do a DNS request.

dns, whois

dns is done

dns is very rudimentary on linux

Small optimization:


Graham, if you try to connect to a host with an ip as a string, then 
a DNS lookup is performed even if it's useless.

On the other side, if you provide an ip as a tuple, no lookup is 
performed and it's a straight connection.


So as an example, when you enter in PASV mode (ftp proto) try this 
instead.

data-address: to-tuple to-block form copy/part tmp 4

Sorry, TCP, DNS, probably UDP, and files/directories are also needed 
for beta.

slightly less functional than the dns scheme

== make object! [
    name: 'dns
    title: "DNS Lookup"
    spec: make object! [
        title: none
        scheme: none
        ref: none
        path: none
        host: none
        port-id: 80
    ]
    info: none
    actor: make native! [[end!]]
    awake: make function! [[event][print event/type true]]
]

The only news is recent Twitter post: "AltME.com website, DNS, WNS, 
and various other changes quite disruptive today, but should settle 
down soon."

ah, nevermind. seems to be a DNS issue.

DNS problem:
   http://www.rebol.com/article/0493.html

I've made a change in red-lang.org domain's DNS setup, we'll see 
in 3 hours if it fixes the naked domain redirection issue.

Redirection of red-lang.org to www.red-lang.org seems to be working 
ok now from here (testing from REBOL console). It might need a few 
more hours for the DNS change to propagate everywhere.