Google+ is dead. Granted people have been saying that much for years now, but this time it’s really true. As of April, Google’s social media experiment will officially go the way of Reader, Buzz, Wave, Notebook, and all the other products that the search giant decided they were no longer interested in maintaining. Unfortunately in the case of Google+, the shutdown means losing a lot of valuable content that was buried in the “Communities” section of the service. Or at least that’s what we all thought.
Thanks to the efforts of [Michael Johnson], many of those Google+ communities now have a second chance at life. After taking a deep dive into the data from his own personal Google+ account, he realized it should be possible to write some code that would allow pulling the content out of Google’s service and transplanting it into a Discourse instance. With some more work, he was even able to figure out how to preserve the ownership of the comments and posts. This is no simple web archive; you can actually log into Discourse with your Google account and have all of your old content attributed to you. Continue reading “Google+ Communities Won’t Go Down Without a Fight”
Your eyes pop open in the middle of the night, darting around the darkened bedroom as you wonder why you woke up. Had you heard something? Or was that a dream? The matter is settled with loud pounding on the front door. Heart racing as you see blue and red lights playing through the window, you open the door to see a grim-faced police officer standing there. “There’s been a hazardous materials accident on the highway,” he intones. “We need to completely evacuate this neighborhood. Gather what you need and be ready to leave in 15 minutes.”
Most people will live their entire lives without a scenario like this playing out, but such things happen all the time. Whether the disaster du jour is man-made or natural, the potential to need to leave in a big hurry is very real, and it pays to equip yourself to survive such an ordeal. The primary tool for this is the so-called “bugout bag,” a small backpack for each family member that contains the essentials — clothing, food, medications — to survive for 72 hours away from home.
A bugout bag can turn a forced evacuation from a personal emergency into a minor inconvenience, as those at greatest risk well know — looking at you, Tornado Alley. But in our connected world, perhaps it pays to consider updating the bugout bag to include the essentials of our online lives, those cyber-needs that we’d be hard-pressed to live without for very long. What would a digital bugout bag look like?
Continue reading “Ask Hackaday: What’s in Your Digital Bugout Bag?”
When spending time camping, people often bring lanterns, flashlights, and the like — you might even bring along a solar charger. Instructables user [bennelson] is combining all your electrical powered needs by cramming solar power into a can.
Already designed to resist the elements, [bennelson] is using a 50cal. ammo can for a portable enclosure. Inside, he’s siliconed a 15AH, 12V lead-acid battery in the centre to maintain balance and to leave room for the wiring and storage. One cardboard mockup later, he laser-cut the top panel from 1/8″ plywood and secured a 20A solar charge controller, a four-in-one socket panel, and two banana plugs on its top face.
[bennelson] is using 12 AWG wire to match the 20A rating of the solar charge controller — including a fuse for safety — and lever lock-nut connectors to resolve some wiring complications. Industrial velcro keeps the top panel in place and easily removed should the need arise. When he’s out camping, he uses an 18V, 1A solar panel to charge, but can still use a DC power adapter to charge from the grid. Check out the full build video after the break!
Continue reading “Solar Power In A Can!”
Has work been a little stressful this week, are things getting you down? Spare a thought for an unnamed sysadmin at the GitHub-alike startup GitLab, who early yesterday performed a deletion task on a PostgreSQL database in response to some problems they were having in the wake of an attack by spammers. Unfortunately due to a command line error he ran the deletion on one of the databases behind the company’s main service, forcing it to be taken down. By the time the deletion was stopped, only 4.5 Gb of the 300 Gb trove of data remained.
Reading their log of the incident the scale of the disaster unfolds, and we can’t help wincing at the phrase “out of 5 backup/replication techniques deployed none are working reliably or set up in the first place“. In the end they were able to restore most of the data from a staging server, but at the cost of a lost six hours of issues and merge requests. Fortunately for them their git repositories were not affected.
For 707 GitLab users then there has been a small amount of lost data, the entire web service was down for a while, and the incident has gained them more publicity in a day than their marketing department could have achieved in a year. The post-mortem document makes for a fascinating read, and will probably leave more than one reader nervously thinking about the integrity of whichever services they are responsible for. We have to hand it to them for being so open about it all and for admitting a failure of their whole company for its backup failures rather than heaping blame on one employee. In many companies it would all have been swept under the carpet. We suspect that GitLab’s data will be shepherded with much more care henceforth.
We trust an increasing amount of our assets to online providers these days, and this tale highlights some of the hazards inherent in placing absolute trust in them. GitLab had moved from a cloud provider to their own data centre, though whether or not this incident would have been any less harmful wherever it was hosted is up for debate. Perhaps it’s a timely reminder to us all: keep your own backups, and most importantly: test them to ensure they work.
Thanks [Jack Laidlaw] for the tip.
Rack server image: Trique303 [CC BY-SA 4.0], via Wikimedia Commons.
[Filipe] has been playing around with custom firmware for inexpensive IP cameras. Specifically, he has been using cameras based on a common HI3815 chip. When you are playing around with firmware like this, a major concern is that you may end up bricking the device and rendering it useless. [Filipe] has documented a relatively simple way to backup and restore the firmware on these cameras so you can hack to your heart’s content.
The first part of this hack is hardware oriented. [Filipe] cracked open the camera to reveal the PCB. The board has labeled serial TX and RX pads. After soldering a couple of wires to these pads, [Filipe] used a USB to serial dongle to hook his computer up to the camera’s serial port.
Any terminal program should now be able to connect to the camera at 115200 baud while the camera is booting up. The trick is to press “enter” during the boot phase. This allows you to log in as root with no password. Next you can reset the root password and reboot the camera. From now on you can simply connect to the phone via telnet and log in as root.
From here, [Filipe] copies all of the camera’s partitions over to an NFS share using the dd command. He mentions that you can also use FTP for this if you prefer. At this point, the firmware backup is completed.
Knowing how to restore the backup is just as important as knowing how to create it. [Filipe] built a simple TFTP server and copied the firmware image to it in two chunks, each less than 5MB. The final step is to tell the camera how to find the image. First you need to use the serial port to get the camera back to the U-Boot prompt. Then you configure the camera’s IP address and the TFTP server’s IP address. Finally, you copy each partition into RAM via TFTP and then copy that into flash memory. Once all five partitions are copied, your backup is safely restored and your camera can live to be hacked another day.
[Matthew’s] recent blog post does a good job explaining the basics of the Raspberry Pi’s file system. The Linux operating system installed on a Pi is generally installed on two different partitions on an SD card. The first partition is a small FAT partition. All of the files on this partition are used for the initial booting of the Pi. This partition also includes the kernel images. The second partition is the root file system and is generally formatted as ext4. This partition contains the rest of the operating system, user files, installed programs, etc.
With that in mind you can deduce that in order to backup your Pi, all you really need to do is backup all of these files. [Matt] has written some scripts to make this a piece of cake (or pie). The first script will simply copy all of the files into a gzipped archive. You can save this to an external SD card, USB drive, or network share.
The second script is perhaps more interesting. This script requires that you have one free USB port and a USB SD card reader. The script will automatically format the extra SD card to contain the two critical partitions. It will then copy the “boot” files to the new boot partition and the root file system files to the new SD card’s root partition. When all is said and done, you will end up with an SD card that is an exact copy of your current running file system.
This can be very handy if you have multiple Pi’s that you want to run the same software, such as in a Pi cluster. Another good example is if you have spent a lot of time tweaking your Pi installation and you want to make a copy for a friend. Of course there are many ways to skin this cat, but it’s always fun to see something custom-built by a creative hacker.
[Frank] knows how important backups are for data security, but his old method of plugging a hard drive in to take manual backups every so often is not the most reliable or secure way of backing up data. He realized he was going to need a secure, automated solution. He didn’t need a full-sized computer with a ton of power; why waste electricity for something so simple? His solution was to use a Raspberry Pi as the backup computer.
The main problem he faced with the Pi was finding a way to make it rack mountable. [Frank] started with an empty 1U server case. He then had to bend a few metal plates in order to securely mount the backup drive into the case. A couple of small rubber pads help dampen any vibrations caused by the hard drive.
The computer power supply was able to put out the 12V needed for the hard disk, but not the 5V required to run the Pi. [Frank’s] solution was to use an LM2596 based switching supply to turn the 12V into 5V. He soldered the power supply wires directly to the Pi, thinking that a USB plug might vibrate loose over time. Mounting the Pi to the computer case should have been the trickiest part but [Frank] made it easy by simply gluing the Pi’s plastic case to the inside of the computer case. When all was said in done, the backup server pulls 29W under full load, 9W with the disk spinning, and only about 2W in an idle state.
On the software side of things, [Frank’s] backup box uses bash shell scripts to get the job done. The Pi connects to his main server via VPN and then the bash scripts use rsync to actually collect the files. The system not only saves backups every night, but also keeps week old backups just in case. If you are really paranoid about your backups, try hooking up a custom battery backup solution to your Pi. If a Pi just isn’t doing it for you, you can always try one of many other methods.