Re: Social engineering phone support.
So you're buying phone and internet from a cable TV company :-) On 04/09/07, Chris AKA personthingy wrote: This may be true, but doesn't explain why telecom phones, and ihug (dish pointing at the hill) pushed me towards Telstra so many years ago for a combined service. IIRC, i ended up with more for about half the price.. On Monday 03 September 2007 22:29, Don Gould wrote: You buy wine from a beer company and what do you expect you'll get? You buy beer from a wine company and what do you expect you'll get? You try to by internet from a telephone company... (we know what you got). You by internet from an internet company and you'll get internet.
Re: Social engineering phone support.
Sad but true, and as far as i can tell, it's the best option! :-/ On Tuesday 04 September 2007 18:22, yuri wrote: So you're buying phone and internet from a cable TV company :-) On 04/09/07, Chris AKA personthingy wrote: This may be true, but doesn't explain why telecom phones, and ihug (dish pointing at the hill) pushed me towards Telstra so many years ago for a combined service. IIRC, i ended up with more for about half the price.. On Monday 03 September 2007 22:29, Don Gould wrote: You buy wine from a beer company and what do you expect you'll get? You buy beer from a wine company and what do you expect you'll get? You try to by internet from a telephone company... (we know what you got). You by internet from an internet company and you'll get internet.
Re: US web sites unreachable
On Tue, 4 Sep 2007, Kim Robertson wrote: These have changed again.. These are the ones that are automatically obtained.. 202.27.184.17 and 202.27.184.18 Are you sure, I've got a fairly long session but I got: Sun Jul 15 14:47:14 2007 : STATUS ALARM: PPP Event: NCP Got secondary DNS address: 202.27.156.72 Sun Jul 15 14:47:14 2007 : STATUS ALARM: PPP Event: NCP Got primary DNS address: 202.27.158.40 and the IPs you give don't appear to even answer DNS queries. Are you with Xtra? From Kim On 3/09/2007, at 8:53 PM, Simon Lyall wrote: On Mon, 3 Sep 2007, Christopher Sawtell wrote: you can also add other name-servers your /etc/resolv.conf 210.55.105.82 and 130.217.66.99 are two possible numbers for people in NZ. resolv.conf only allows 3 servers usually (well it allows more but ignores them). If you are using Xtra's name servers make sure you arn't using the 202.27.184.3 and 202.27.184.5 *alien and terminator) . The 202.27.158.40 and 202.27.156.72 ones are what they tell people to use (and the you should get automaticly when you login). But I havn't seen any problem with DNS recently. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ To stay awake all night adds a day to your life - Stilgar | eMT. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ To stay awake all night adds a day to your life - Stilgar | eMT.
Re: Debian 3.1 timezone update
On 04/09/07, Volker Kuhlmann [EMAIL PROTECTED] wrote: A paperweight? For just having a clock out by an hour in one timezone? Wow. A computer which can't show the time right is pretty bad IMHO. This is sort of OT now, especially because *you* know all this, but for the sake of the wider readership ... There's nothing wrong with the OS clock, that runs in UT (Universal Time), and is kept correct by either sheer luck, or the NTP daemon. When a user (and this includes server programs) asks to see what the time is, the OS will translate UT into your timezone. Each user can have their shell operating in a different timezone if they like, by just changing the TZ environment variable. If there is no TZ variable, the default is basically the contents of /etc/timezone Because NZ has recently (and with what could really be termed insufficient notice; and some may argue insufficient reason - a 42000 person petition doesn't really convince me) changed the dates on which the NZ timezone will shift into Daylight Savings mode, the extensive database that Unix machines use needs an update. http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Resource-material-Information-We-Provide-About-Daylight-Saving?OpenDocumentExpandView Daylight saving now runs from the last Sunday in September until the first Sunday in April. This database for most distributions of Linux and Unix is the Olsen Database, have a look at http://www.twinsun.com/tz/tz-link.htm for te sort of work these people put in to looking after time zone info. The current revision of the database itself is fine, of course. Rule NZ 2007 max - Sep lastSun 2:00s 1:00 D Rule NZ 2008 max - Apr Sun=1 2:00s 0 S http://search.gmane.org/search.php?group=gmane.comp.time.tzquery=new+zealand Yes of course, replacing /etc/localtime (and a few of the same under /usr/share/zoneinfo to be safe) with the file from SUSE (or any other distro which does publish an update) is trivial, but bypassing the packaging system comes at the expense of the obvious drawbacks. Hence a new package would be the better solution, but if there isn't one, the manual fix is the right one. It sounds like a manual fix will be required, sadly. However you may enjoy editing the local rulebase and compiling it, rather than copying in data from another distro. Grab the latest tzinfo files from twinsun, extract them in a temporary location, and then use 'zic' to compile the 'australasia' file. zic will overwrite the correct system binary files with the compiled result (yes, you should be root to do so). Test with zdump -v Pacific/Auckland | grep '200[78]' Actually, test before the 'zic', and after. Enjoy. I realise 3.1 is (obviously) no longer supported, but an upgrade to 4 is out of the question. One has to stabilise at some point. Sure, agreed. I think the risks of compiling your own tz data files are pretty low, even in the face of a later update to libc6. -jim
Re: Microsoft letter todays Christchurch Press re Open XML
Apparently we voted no to OpenXML getting it's ISO certification, here is the link http://www.builderau.com.au/news/soa/NZ-rejects-Microsoft-OOXML-Sweden-confused/0,339028227,339281682,00.htm
Re: Debian 3.1 timezone update
On Tue, September 4, 2007 9:25 pm, Jim Cheetham wrote: On 04/09/07, Volker Kuhlmann [EMAIL PROTECTED] wrote: A paperweight? For just having a clock out by an hour in one timezone? Wow. A computer which can't show the time right is pretty bad IMHO. This is sort of OT now, especially because *you* know all this, but for the sake of the wider readership ... There's nothing wrong with the OS clock, that runs in UT (Universal Time), and is kept correct by either sheer luck, or the NTP daemon. When a user (and this includes server programs) asks to see what the time is, the OS will translate UT into your timezone. Each user can have their shell operating in a different timezone if they like, by just changing the TZ environment variable. If there is no TZ variable, the default is basically the contents of /etc/timezone Because NZ has recently (and with what could really be termed insufficient notice; and some may argue insufficient reason - a 42000 person petition doesn't really convince me) changed the dates on which the NZ timezone will shift into Daylight Savings mode, the extensive database that Unix machines use needs an update. http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Resource-material-Information-We-Provide-About-Daylight-Saving?OpenDocumentExpandView Daylight saving now runs from the last Sunday in September until the first Sunday in April. This database for most distributions of Linux and Unix is the Olsen Database, have a look at http://www.twinsun.com/tz/tz-link.htm for te sort of work these people put in to looking after time zone info. The current revision of the database itself is fine, of course. Rule NZ 2007 max - Sep lastSun 2:00s 1:00 D Rule NZ 2008 max - Apr Sun=1 2:00s 0 S http://search.gmane.org/search.php?group=gmane.comp.time.tzquery=new+zealand Yes of course, replacing /etc/localtime (and a few of the same under /usr/share/zoneinfo to be safe) with the file from SUSE (or any other distro which does publish an update) is trivial, but bypassing the packaging system comes at the expense of the obvious drawbacks. Hence a new package would be the better solution, but if there isn't one, the manual fix is the right one. It sounds like a manual fix will be required, sadly. However you may enjoy editing the local rulebase and compiling it, rather than copying in data from another distro. Grab the latest tzinfo files from twinsun, extract them in a temporary location, and then use 'zic' to compile the 'australasia' file. zic will overwrite the correct system binary files with the compiled result (yes, you should be root to do so). Test with zdump -v Pacific/Auckland | grep '200[78]' Actually, test before the 'zic', and after. Enjoy. I realise 3.1 is (obviously) no longer supported, but an upgrade to 4 is out of the question. One has to stabilise at some point. Sure, agreed. I think the risks of compiling your own tz data files are pretty low, even in the face of a later update to libc6. -jim The other thing thats worth knowing is that it doesn't matter whether your hardware clock is set to UTC or local time. The hardware clock is only used on boot, and saved to on shutdown. While the computer is running the time is taken from the kernel (which may be augmented by ntp). the kernel keeps time in UTC, and (as Jim says) is translated to any arbitrary timezone by your system settings). So the procedure is: A. A system variable tells you what timezone the hardware clock is kept in (UTC or localtime). B. On boot the hardware clock is read and (if necessary, depending on the value of the variable) converted to UTC to feed to the kernel. C. The kernel chunters along in UTC, augmented by NTP until shutdown. D. On shutdown the kernel time is (if necessary) converted to whatever timezone is stored in the hardware clock and saved there for use on the next boot. Unix systems traditionally set the hardware clock to UTC, but (some, maybe not all) windows systems expect the hardware clock to be in localtime, so if you are dual booting, setting the hardware clock to localtime is the safest. If you have a *nix only system either will be fine, so long as you don't chop change, and as long as the system knows which choice you made. -- Nick Rout
Thursday workshop + SFD
7.30pm. 6 September at Sydenham Community Centre, 25 Hutcheson Street. Hands-on PC help session. Bring your computer along for install or repair, ask questions, meet other users, network. Debian/Ubuntu and GNOME specialists, BSD supporters. Free / Open-Source Software install/live CDs available. Light supper provided, donations cover costs, all welcome. Facilitation to http://SoftwareFreedomDay.org - a chance to review plans for 15 16 Sept Installfest/demo-day. T-shirts are here. Cheers, Rik
Re: Debian 3.1 timezone update
just changing the TZ environment variable. If there is no TZ variable, the default is basically the contents of /etc/timezone /etc/localtime Because NZ has recently (and with what could really be termed insufficient notice; and some may argue insufficient reason - a 42000 person petition doesn't really convince me) I go with insufficient notice, interestingly a large number of other countries seem to have made changes now as well. Insufficient reason is arguable - it would be smart to change daylight savings at the same time as most/many other countries, like the EU is now all the same. Pity NZ didn't take those rules. What other countries are they now the same as? It sounds like a manual fix will be required, sadly. However you may enjoy editing the local rulebase and compiling it, rather than copying in data from another distro. I would enjoy that, but neither I nor the person paying me for it make it high priority, and as zdump -v NZ produces the same output I feel confident that copying the zoneinfo file from somewhere is just fine. ;) Btw here's another short test: env TZ=NZ date -d 2008-03-28 14:00 utc +%a %Y-%m-%d %T %Z The correct time is 3:00, the wrong (old rules) time is 2:00. Or we can play (copy and paste into shell as 1 line!): sh -c 'export TZ=NZ; test `date -d 2008-03-28 14:00 utc +%H` = 03 echo Right || echo WRONG' Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: Debian 3.1 timezone update
On Wed, September 5, 2007 10:42 am, Volker Kuhlmann wrote: Btw here's another short test: env TZ=NZ date -d 2008-03-28 14:00 utc +%a %Y-%m-%d %T %Z The correct time is 3:00, the wrong (old rules) time is 2:00. Or we can play (copy and paste into shell as 1 line!): sh -c 'export TZ=NZ; test `date -d 2008-03-28 14:00 utc +%H` = 03 echo Right || echo WRONG' Volker There is a little c test program in this message (which also gives another set of instructions on how to fix the underlyting problem). http://www.linux.net.nz/pipermail/nzlug/2007-August/010186.html -- Nick Rout
Re: On Topic Linux Question :-) Traffic report out of IPCop box.
I used to use the add in traffic control and reporting. (It allowed me to limit usage by ip address.) The other thing it did was summarise usage by ip address and send me an email each day - and, optionally, the user as well. On 03/09/07, Christopher Sawtell [EMAIL PROTECTED] wrote: Anybody know if it's possible to get a traffic report sorted by internal IP number out of an IPCop box? If so how? -- Sincerely etc. Christopher Sawtell
Re: US web sites unreachable
Hi, Hmm.. Thats interesting... strange.. They have changed again... ns1.xtra.co.nz 202.27.184.17 ns1.xtra.co.nz 202.27.184.18 From Kim On 4/09/2007, at 8:01 PM, Simon Lyall wrote: On Tue, 4 Sep 2007, Kim Robertson wrote: These have changed again.. These are the ones that are automatically obtained.. 202.27.184.17 and 202.27.184.18 Are you sure, I've got a fairly long session but I got: Sun Jul 15 14:47:14 2007 : STATUS ALARM: PPP Event: NCP Got secondary DNS address: 202.27.156.72 Sun Jul 15 14:47:14 2007 : STATUS ALARM: PPP Event: NCP Got primary DNS address: 202.27.158.40 and the IPs you give don't appear to even answer DNS queries. Are you with Xtra? From Kim On 3/09/2007, at 8:53 PM, Simon Lyall wrote: On Mon, 3 Sep 2007, Christopher Sawtell wrote: you can also add other name-servers your /etc/resolv.conf 210.55.105.82 and 130.217.66.99 are two possible numbers for people in NZ. resolv.conf only allows 3 servers usually (well it allows more but ignores them). If you are using Xtra's name servers make sure you arn't using the 202.27.184.3 and 202.27.184.5 *alien and terminator) . The 202.27.158.40 and 202.27.156.72 ones are what they tell people to use (and the you should get automaticly when you login). But I havn't seen any problem with DNS recently. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ To stay awake all night adds a day to your life - Stilgar | eMT. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ To stay awake all night adds a day to your life - Stilgar | eMT.
