ionFish

I can't thank you enough for your help so far. I'll sit down and troubleshoot it later this week.

If you're going to test it, you may want to remove some of the releases and one of the architectures from the top of the file. Otherwise, you'd end up downloading/packaging 12 different systems.

I was sure that would work -- but it returns the same error as posted prior. I put the script on GitHub github.com/ionfish/chronobin (the problems are in 'chronogen.php' starting on line 107. Thanks again for your time.

This '/etc/debootstrap/locale.gen' seems promising.

Thanks for the suggestion though, I definitely look forward to testing that package out.

3. I will do so when I get the chance. But I simply don't need all of the features provided by 'grml-debootstrap'. The scripts I have total maybe 400 lines, and don't require anything installed except for 'debootstrap' to make templates, which is not intended to be done by the end user at all. The templates unzip in seconds, whereas one would have to download packages and wait for them to configure otherwise.

2. I used 'dpkg-reconfigure locales' manually last time, and it worked, except that it has a menu interface and does not work with my script (not interactive). I do get those same errors as pasted before.

1. 'man' was not installed, so I did so, and it tells me the configuration is at '/etc/belocs/locale-gen.conf' which not surprisingly, does not exist.

Of course I could make these templates (just a tar.gz of the debootstrap files) and patch them by hand, but when you mix in 32/64 bit architectures with the many releases of Debian and Ubuntu, it becomes so much of a hassle to keep everything updated. This way I can run it on a daily- or weekly-cron on a server somewhere and not have to worry about outdated systems.

It's the fastest way that I have found to make a clean, reliable sandbox environment for testing scripts and compiling stuff quickly. The problems I have come from when I use ANOTHER script I'm working on to try to automatically generate these "templates" (and patch the locales errors).

xpt - This is all part of a chroot script I am writing. I can give you the source, or even access to a test server, and you can investigate further. The reason why I have to make a script for it is because it's purely temporary -- once you type 'exit' all of the files are deleted.

'locale-gen' reports no errors (in fact it shows nothing).

Here's a log of ALL error messages related to the locales: fpaste.org/14879/70688713/raw

Oh, silly me. Thanks. I'll post results shortly.

I get the following error still while installing software to the system: fpaste.org/14822/83369136/raw . Any suggestions? Thanks.

So would something like cat "en_US.UTF-8 UTF-8" > /etc/locale.gen or to the Ubuntu path, then running locale-gen, make sense to do?

Yeah I was about to go to bed. Click my username, go to my homepage, click the contact page and then drop me a message. I will respond tomorrow.

You'd want to set your mail server up FIRST.

Because the server you use to send mail does not require any modifications to your domain, whereas you need to set up records to receive mail on your domain. I was only suggesting to use A-records for your mail subdomain because you should give it a static IP and it will also save a few fractions of a second of lookup time. Instead of resolving mail >> subdomain >> IP, it would go mail >> IP.

You should first read how mail delivery works; CNAME records would be added of your choice (mail.domain.com or smtp.domain.com etc.) And you'd likely want to use A-Records since you should already be using an IP address that does not change. Dynamic IPs can complicate some mail delivery if it changes but the DNS record is cached elsewhere. Your MX records will be only for if you want to use mail on your domain (receiving mail).

DoveCot has IMAP but you will need to find another authentication daemon for SMTP. PostFix is a good choice for it, tutorial here: exratione.com/2012/05/….

Not at all; your DNS records are set on the domain's name servers (or your DNS server if you operate one). They simply resolve domain names into IP addresses which allows people and computers both to find your server. Your Apache server wouldn't even know that there is another subdomain.

For beginners, definitely DoveCot. As you'll notice with PostFix, it has many many more configuration options. You can try both, even. But for you, I recommend DoveCot.

One thing to point out. Do NOT set a cronjob for 'ntpdate pool.ntp.org' every 24 hours, or something similar. I've seen several people take this approach.

Friend sent me this a few weeks ago: ponybot.net/pix/4526.gif

Alright, a few bugs. I have to still make it ignore duplicate links, and not fail with #links like that.

90% done!!! It's working perfectly, just have to do some formatting and make it not timeout for massive sitemaps like yours.

Now, it extracts all URLs from the XML file, and opens them all up and searches yet again for all the links inside the pages themselves. Almost done!

Ok, so far, it downloads the remote file and tells whether it's valid or not, and maybe 20% done development. So in a few hours? Bah. PHP is fun. Time is not.

Hopefully you got it.

Sure, talk to you later. You can email me too, I sent a mail to you.

20 bucks a month for like, 8 slots, static ip.

And people pay good money for it.

I never played it, just that setting up a few headless linux boxes to run the game costs almost nothing.

Easy money -- Minecraft servers.

We have a lot of other stuff that's not on the site, mainly because it's private work for individuals and businesses. (Bank websites, etc.)

Thanks. But it's much better. Those are old snaps.

But yeah, that could work. Not a priority, big project to be released Saturday.

Use it to spam small websites so that they go offline.

Or try to remotely include a shell script and hack their way into the server? Or worse...

My servers? Don't worry about that. I could securely host it, but it would likely be a paid service. Someone could submit a sitemap like yours, and use like 500 megs of bandwidth a minute.

The script I'm writing only validates it's "valid XML" and will just extract raw URLs from it to test. It should be flexible for all.

I changed it so that you enter the URL of a sitemap rather than upload the file, because then you don't have to download it in the first place. And perhaps I'll adapt it into a tool on our site, but very unlikely because fetching "remote URLs" from "strangers" can be very, VERY dangerous. And thanks, I'll email you now so you have my email.

"fortunately, I havn't hit the button that will break it yet" That sounds like the Big Red Shiny Button. Be careful. And make backups.

That's pretty crazy. But I think cURL is faster than that, so I don't know. You'll have to experiment. I mean, it's a learning experience for me too. I've never made a tool to spider and check entire websites for 404's. Hopefully it works, and you get your site fixed. I'm at about 90 lines of code right now.

It won't necessary require that much CPU power at all, it just takes a while to run because it has to use HTTP to open each and every page, and scan that. Since it's PHP, it has to be left running and you'll know it's done only when my script prompts you to download the output. Best advised to set up your domain as "127.0.0.1" in the Windows Hosts file and use a local copy to scan.

I am going to make the source public for the community when it's done. Shouldn't be too much longer. Wait, check each page from that sitemap for dead links within that page (1 page to another) like open each page FROM the sitemap, scan the whole page for dead links? Or just find dead links from the sitemap itself?

Hmm, yes I misunderstood. I'm still going to work on this, though it will take a bit longer. It will take quite a while to run, and use a good bit of memory. Though I'll even make it send a text file with the dead links to download, rather than output all of them on the page. I'm thinking hierarchical like "Sitemap link: (new line and indent) [dead link]" and list all dead links under the page it's contained in. Or is it better to list all unique dead links in one shot?

I am writing you a PHP script right now, which will let you upload a sitemap, press go, and then check each link for a 404 (obviously I can't test it for you since it's a local site, you said.) It will output (one per line) the URL to the dead pages only. I could also make it show dead ones in RED and good links in GREEN. Let me know soon, before I finish the script. I'll post it as an answer after I'm done. If possible, can you upload your sitemap to Pastebin or something? It will help greatly.