Jason Cooper

You do realise that you can set up a server so that you can manage it remotely. Some of the servers I am responsible for are in a machine room next to me, others are located on the other side of the world. I use SSH for managing all of them (If you are using a windows server then there are similar remote access options available). That would let you leave the machine anywhere that your IT Department policies dictate and still give you access. If the machine has a habit of locking up completely or stopping you accessing it remotely and needs physical interaction (restarting a service or rebooting the whole machine) then figure out the cause of the problem and fix it. That was my first thought after reading Lupis's post. Talk to your IT department, they will be able to help. They may well be able to offer you a virtual server in the DMZ with remote access. If they won't help then get the most senior person you can in your department to talk their head of department. You would be surprised how quick an IT department can become helpful when their department head has been complained to.

I think you are confusing a DMZ with a DMZ host option that you find on SOHO routers. A proper DMZ doesn't expose every port on every machine in it. They are sat behind a firewall which blocks access to all ports except the ones you want open. There is also a firewall sat between the machines on the DMZ and the rest of your internal network. This blocks access to your machines from your server, and potentially to your server from your machines. A DMZ doesn't make a host more vulnerable to attacks it gives attackers another hurdle to get through if they do manage to get control of your exposed server. Of course if Lupius is talking about using a SOHO router then he would be better off sticking with external hosting (perhaps a VPS if they need it to do more than hosting web pages).

Maintaining tunnels like this is not a great idea. You are effectively giving everyone a tunnel to a specific port on a specific machine inside your firewall. Also you would need to make sure that the tunnel would always be up, which would involve making sure that it is created when either machine is restarted and if the ssh process fails on either machine. Also there would be performance issue your bandwidth would be limited by the lowest bandwidth in the route between the browser, your web server proxy and your new web server. It would be a much better idea to make sure your corporate network has a demilitarized zone (DMZ) which you can put your web server, and any public facing services, in. This would let you keep it separated off from your main network and then you can open a hole in your firewall for it. Finally after you have it up and running you can change the DNS for your old web server to point to your new web server.

I have seen similar problems with an older server where the RAID controller would suddenly lock up. The server just locked up from the point of view of connecting to it as it couldn't write to the disk, though it could output errors to the console and over the network to our syslog server. Do you have another Linux machine on the same network? If so then set up syslog on your laptop/server to send a copy of all its logs to your other Linux machines syslog server. That way when your machine locks up because it can't write to the disk it will still be able to log errors over the network to your other machines syslog server.

As the others have said check the JavaScript error console and see if it is complaining about anything (don't have a JavaScript console then install chrome or Firefox with the firebug plugin). If the jQuery files and directory aren't there then upload them. If they are there but the web server can't serve them then check the owners and permissions of the jQuery files and directory and make sure that the web server can access it.

I can see where you are coming from now. I was reading it as "the compiler producing more efficient code" rather than "the compiler being more efficient at producing optimized code". Having cleared that up, I agree :)

So you use assembler a lot then? I assume you meant "because good compilers will optimize for the CPU more efficiently than most humans could." There are still some times when a human with knowledge of the CPU/ machine architecture will be able to optimize a program for speed much better than a compiler. Of course this level of optimized code is not needed for most software, but for embedded systems can be critical. This is a very good point that lots of people miss. The language you are using to write one sort of program may not be as suitable for a different type of program. I use Perl for data processing and quick prototyping. For writing a boot block I wouldn't use Perl though, I would use assembler (Probably FASM but that is just personal preference) as this would give me the level of control of the machine code produced that I would require.

If they are just listening in, which they can do with an unsecure network or one they have a pre-shared key (password) for, rather than actively intercepting with a man in the middle attack then there are 3 different types of data they will be able to capture. Packet headers : They will get to see the source and destination information for each packet, as well as other bits of information stored in the packet headers, (Ethernet frame headers, IP Headers, TCP/UDP/ICMP/etc headers) Clear text : Any protocols that don't use encryption will be passing their data in an unencrypted form (standard HTTP, SMTP, IMAP, POP3, FTP, etc). This could easily contain passwords, usernames and other important/confidential information. Cipher text : Any protocols that use encryption properly will be passing their data in an encrypted form (HTTPS, IMAPS, SSH, SFTP, etc). To do anything with this information the attacker would have to be able to break the encryption in some way, which puts it out of the reach of most attackers. It is important to note that even when using protocols that use encryption the packet headers will be available, they can't be encrypted or routers wouldn't be able to route the packets. This lets an attacker perform traffic analysis on any sniffed data, so they can see that you SSH into a box and how long you are on there, even if they can't see what you are doing while you are on there. Traffic analysis can be very powerful, especially when combined with information gathered from protocols that don't use encryption. E.G. that box you SSH into may well be broken into as you use the same username and password on your router which you login to over HTTP.

If using tcpdump don't forget to set your snap length (-s) or you won't necessarily be collecting full packets. I usually use a snap length of 0 which should capture the full packets, I believe that most OS's will default it to 68 bytes which is enough to grab most packets headers but not their data.

I don't use it regularly, only if I am having to email someone a password. Then again most of my emails are either not leaving the organisation or are going to mailing lists. If I was in a different sort of business then I would probably be using it as default and making sure that I get the public keys directly off (in person) those I would be emailing so as to build up a set of public keys that I actually can trust.

Over the past week or so there has been a number of things going on with the forum, but they seem to be slowly fixing them. I would imagine that the more commonly used features that are broken will be higher up the list. You could always give the RSS feeds a try instead of the email digests. They may not be as detailed but they should be working.

I would suggest looking at ExifTool as it can be used from the command line it should be easy enough to process 900 pictures once you have figured out the correct options to use. There is an example on the website for shifting images timestamps, so I would start there. Just remember to take a backup of your pictures before modifying them.

But we can make some educated guesses as to what it might be. I haven't seen raw audio files since I moved from my Amiga to using a PC. So that is unlikely. Video footage in a raw form would take up masses of disk space, so again that would seem unlikely. Images on high spec cameras (or lower spec cameras using lovely open source firmware) are quite often set to save images in a their raw format. Which suggests that his .raw file is probably an image. Of course this doesn't mean that it is an image file, but it is a good guess as to what the file could contain.

I assume the computer isn't reporting any errors, be it in a popup box or via the event log. Does the printer have an online interface (e.g. web, ssh or telnet)? If so connect to that and have a look at what its status is when it pauses halfway through printing. Also check to see if it has logged anything. Sometimes printers can get caught up processing complex graphics and take a long time to print. One thing you could try is looking in the printers settings and see if it is set to print vector graphics. If so try changing it to raster graphics. It will take longer and not look as good but it will be less processor intensive on the printer as it isn't having to render complex images just a big bitmap.

.raw files usually mean that they haven't been processed and just contains the data received from a device, these days it is most commonly related to high spec digital cameras. If it is a RAW image file try dcraw.

I assume you mean 192.168.0.0/16 :) I think the point is though that he wants them on two different subnets. The big question would then be is his WAP a router as well, or could his WAP be attached to his router directly rather than through the hub. Either would make his life a lot easier.

Just looking at it and this loop jumps out as being inefficient. for (i = 0; i < len; i++) { buf[i] = '-'; buf[i+1] = '\0'; } Every time round the loop you put write to two locations in memory when you could do for (i = 0; i < len; i++) { buf[i] = '-'; } buf[i] = '\0';

A while ago after watching the cold boot attack episode of Hak5 I wrote a memory dumping tool called memDump. It is crude and only supports dumping between 16MB and 4GB of memory (i.e. it is only 32bit), but it does fit entirely in a standard bootblock so it only overwrites 512b of memory. The source is included in the downloads (FASM Assembler) It worked fine on my test machines but I have only a limited number of test machines so if anyone else tries it and finds any bugs please let me know.

The kernels data structures store lots of information that can make your life a lot easier. Booting an entire kernel to dump the memory (Like some of these memory dump tools do) is going to overwrite/corrupt a lot of this data. After all if I am looking to find information from a specific process that was running on the machine before the reboot then it would make a lot of sense to start by working out what areas of memory the process could access.

You will loose at least 512b of memory as on boot the system will have to load in the boot block. Most of the memory dumpers designed to run after a reboot use more memory than just the boot block so you will loose even more memory, not masses but personally I like my memory dump tools to have as little effect on the memory being dumped as possible.

With it being the 1st April I'm taking everything today with a pinch of salt.

There are very few constants in computing, but NASA leaving it's computers wide open is one of them. :)

SSH would be my first port of call and them if I need GUI access I would look at forwarding X over SSH.

One thing to remember is that IPv6 doesn't have any NAT features so your firewall does become even more important than most home networks using IPv4. Instead every thing on your network is theoretically contactable from any other machine using IPv6. This would open up a lot of devices that are currently hidden behind NAT to possible direct attacks. In few years times if you don't configure your firewall correctly then you may find people port scanning your fridge :)

Unless you already have a large lump of data to be put on the new system I would be inclined to get an SSD and add a large hard disk at a later date. Mainly because it is easier to migrate your data onto a new disk than migrate your OS on to a new disk. Also if you do have a large lump of data from a previous system to go on the new one you could always use the hard disk from your old system till you have the money for the large disk.