Whooha, auch der CCC macht mit!
Update: theoatmeal.com had a good explanation why SOPA/PIPA is not a good idea:
$ zypper install man
The following NEW packages are going to be installed:
cups-libs fontconfig ghostscript-fonts-other ghostscript-fonts-std
ghostscript-library groff groff-devx lcms libfreetype6 libgimpprint
libjpeg62 liblcms1 libpng14-14 libtiff3 man
The following recommended packages were automatically selected:
ghostscript-fonts-other ghostscript-library
15 new packages to install.
Overall download size: 14.9 MiB. After the operation, additional 67.8 MiB will be used.
15 new packages, almost 70 MB for a bunch of text files. And why would I need cups-libs or libjpeg62? Luckily, zypper too can be tought not to install recommended packages:
$ zypper install --no-recommends man
The following NEW packages are going to be installed:
groff man
2 new packages to install.
Overall download size: 2.4 MiB. After the operation, additional 10.0 MiB will be used.
Much better :-)
There's an installRecommends switch in /etc/zypp/zypper.conf, but this was not honored by zypper 1.6.18 :-\
$ zypper install --no-recommends nginx
The following NEW packages are going to be installed:
fontconfig gd libfreetype6 libGeoIP1 libjpeg62 libpng14-14 libxslt1 nginx-1.0
xorg-x11-libICE xorg-x11-libSM xorg-x11-libX11 xorg-x11-libXau
xorg-x11-libxcb xorg-x11-libXext xorg-x11-libXpm xorg-x11-libXt
16 new packages to install.
Overall download size: 3.0 MiB. After the operation, additional 11.8 MiB will be used.
Really? openSUSE has bundled a webserver with Xorg libraries? Sigh... I can already smell the b0rkage when the next update is due and zypper is trying to untangle all the dependencies for every friggin' package ever installed because of insane dependencies like this.
You have updates available for other accounts. Sign into the account you used to purchase it.Huh? I don't have any other accounts. One Apple account is more than enough :-\
/Applications/Install Xcode.app resp. Install XCode.dmg, usually found in /Applications as well. Then try again to update Xcode.Disk Utility.app can be used to set up NFS mounts. But as long as automount(8) is supported in MacOS X, let's use this for a more general approach:
$ mkdir /mnt/{nfs,smb}/{a,b}
Then we create automount ''maps'' for each protocol:
$ cat /etc/auto_nfs /mnt/nfs/a -fstype=nfs,rw,resvport 10.0.0.10:/export/foo /mnt/nfs/b -fstype=nfs,ro,resvport 10.0.0.10:/export/bar $ cat /etc/auto_smb /mnt/smb/a -fstype=smbfs,rw ://10.0.0.10/foo /mnt/smb/b -fstype=smbfs,ro ://10.0.0.10/barWith that in place, we have to include both files in auto_master(5)
$ grep -v ^# /etc/auto_master +auto_master # Use directory service /- auto_smb /- auto_nfsTell automountd(8) to flush any cached information:
$ automount -v -cSometimes it's necessary to restart automountd:
$ launchctl stop com.apple.automountd $ launchctl start com.apple.automountdNow the shares should be mounted automatically upon access.
Ignoring unknown extended header keyword `SCHILY.dev' Ignoring unknown extended header keyword `SCHILY.ino' Ignoring unknown extended header keyword `SCHILY.nlink'Hm, what does that remind me of? Ah, star! Digging in the bits still left on BerliOS, there seems to be something what looks like a POSIX proposal:
$ cat star/README.posix-2001
[...]
Star supports the following fields in the extended header:
[...]
Vendor unique:
"SCHILY.devmajor" "SCHILY.devminor" (create/extract)
In -dump mode (a preparation for incremental dumps) star archives:
"SCHILY.dev" The field stat.st_dev - the filesys indicator
"SCHILY.ino" The field stat.st_ino - the file ID #
"SCHILY.nlink" The field stat.st_nlink - the hard link count
"SCHILY.filetype" The real file type - this allows e.g.
socket/door
Wow. Alas, these headers remain unrecognized in GNU/tar, hence the (benign) warnings.
e2fsck (under MacOS 10.4/ppc) only gave:
$ e2fsck -fv /dev/rdisk0s4 fsck.ext3: unable to set superblock flags on /dev/rdisk0s4Then I remembered to try with a dfferent superblock, and it worked perfectly:
$ mkfs.ext3 -n /dev/disk0s4
[...]
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Note: Don't forget the -n option, otherwise mkfs.ext3 will really format the partition!
$ e2fsck -b 32768 -fv /dev/rdisk0s4 [...] $ mount_ext2 /dev/disk0s4 /Volumes/disk0s4/Now mounting succeeds again. Yeah, ext3 ;-)
# cd /usr/ports/shells/ksh93 # make install [...] ===> Building for ksh93-20090505 package: update /usr/ports/shells/ksh93/work/bin/execrate package: cc: seems to be a cross-compiler package: set HOSTTYPE to something other than the native freebsd8.amd64 *** Error code 1This seems to happen every now and then, but I had to go to another bugtracker to find the solution: apparently,
"make install" compiles a small test-program and tries to execute it in /tmp. However, /tmp is mounted noexec and so the test-program fails to execute and in turn the build fails as well. The solution was to mount /tmp with the exec flag:
$ grep /tmp /etc/fstab tmpfs /tmp tmpfs rw,nosuid,exec,mode=1777,size=134217728 0 0Unfortunately, FreeBSD's tmpfs won't allow a remount - we have to umount and the mount again:
$ mount -u -o exec /tmp mount: tmpfs : Operation not supported $ umount /tmp $ mount -o exec /tmp $ mount | grep /tmp tmpfs on /tmp (tmpfs, local, nosuid)
touch(1)), I wanted to test with -w:
$ ls -ld /mnt/usb/foo drwx------ 13 root root 4096 Jan 1 15:38 /mnt/usb/foo $ [ -w /mnt/usb/foo ]; echo $? 1OK,
/mnt/usb/foo is not writable, because /mnt/usb was mounted read-only at this point. But look what dash(1) thinks of this:
$ [ -w /mnt/usb/foo ]; echo $? 0Huh? But the manpage explains:
-w file True if file exists and is writable. True indicates only that the write flag is on.
The file is not writable on a read-only file system even if this test indicates true.
...whereas bash(1) only states:
-w file True if file exists and is writable.Zsh and ksh93 behave just as
bash - that is returning 1 when the file is not writable, even though its permissions would allow for writes. Note that /usr/bin/test is shell-specific as well!
# cat count.sh
i=1
while [ "$i" -lt 10000000 ]; do
((i++))
done
# for i in ksh zsh pdksh mksh bash; do (echo "SHELL: $i"; time $i count.sh); done
SHELL: ksh
real 0m45.196s
user 0m44.676s
sys 0m0.070s
SHELL: zsh
real 1m13.755s
user 1m5.651s
sys 0m7.402s
SHELL: pdksh
real 1m7.300s
user 1m6.013s
sys 0m0.092s
SHELL: mksh
real 1m8.922s
user 1m8.013s
sys 0m0.091s
SHELL: bash
real 3m10.721s
user 3m0.016s
sys 0m6.372s
This was done with ksh from AT&T Research (1993-12-28), zsh 4.3.4, PDKSH v5.2.14, MIRBSD KSH R32 and GNU bash 3.2.39(1) on a MacMini.
$ cat count.sh
i=1
while (( i++ < 10000000 )); do
:
done
$ for i in ksh zsh pdksh mksh bash; do echo "SHELL: $i"; time $i count.sh; done
SHELL: ksh
real 1m59.642s
user 1m58.340s
sys 0m0.012s
SHELL: zsh
real 3m34.747s
user 3m4.588s
sys 0m25.616s
SHELL: pdksh
real 4m15.224s
user 4m10.056s
sys 0m0.028s
SHELL: mksh
real 4m48.835s
user 4m43.480s
sys 0m0.036s
SHELL: bash
real 10m9.914s
user 9m52.724s
sys 0m4.072s
This was done with ksh-93s+ from AT&T Research (2008-01-31), zsh 4.3.10, PDKSH v5.2.14, MIRBSD KSH R39c and GNU bash 4.1.5(1) on a PowerBook G4 (M9691LL/A) (throttled to 750MHz).
$ VBoxManage unregistervm foo --delete
ERROR: Cannot unregister the machine 'foo' because it has 1 snapshots
Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component
Machine, interface IMachine, callee nsISupports
Context: "UnregisterMachine(uuid, machine.asOutParam())" at line 164
of file VBoxManageMisc.cpp
Oh, right. The VM in question had a snapshop attached to it as well, so let's delete it too:
$ VBoxManage showvminfo foo | less
[...]
Snapshots:
Name: snap1 (UUID: 8e2914fa-de59-4842-9391-3afac42e0125)
$ VBoxManage snapshot foo delete 8e2914fa-de59-4842-9391-3afac42e0125
0%...FAILED
Error: snapshot operation failed. Error message: Hard disk '../deb0.vdi' has
more than one child hard disk (2)
Hm, I remember now, the VM was using another VM's disk. Kinda weird setup, no wonder I wanted to get rid of it :-) So let's find out which VM also uses "deb0.vdi":
$ VBoxManage list hdds
[...]
UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657
Parent UUID: base
Format: VDI
Location: ../deb0.vdi
State: created
Type: normal
Usage: foo (UUID: 3c57773a-de6a-4714-9149-407a98f85ae7)
[snap1 (UUID: 8e2914fa-de59-4842-9391-3afac42e0125)]
UUID: bc3b45a9-db44-41a4-822d-52987f2734c8
Parent UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657
Format: VDI
Location: ../foo/Snapshots/{bc3b45a9-db44-41a4-822d-52987f2734c8}.vdi
State: created
Type: normal
UUID: 06280b86-8389-40c4-8bfb-3562a3e206df
Parent UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657
Format: VDI
Location: ../debian/Snapshots/{06280b86-8389-40c4-8bfb-3562a3e206df}.vdi
State: created
Type: normal
Usage: debian (UUID: bdbf5c46-aefe-4004-acea-ac521eaedb2e)
So, "deb0.vdi" was used by VM foo and debian an also by a snapshot. Maybe I could just edit VirtualBox.xml manually, but that wouldn't be that much fun, right? So let's detach 06280b86-8389-40c4-8bfb-3562a3e206df from debian, then we should be able to delete the snapshot, right?
$ VBoxManage showvminfo debian | grep 06280b86-8389-40c4-8bfb-3562a3e206df
SATA Controller (1, 0): ../debian/Snapshots/{06280b86-8389-40c4-8bfb-3562a3e206df}.vdi
(UUID: 06280b86-8389-40c4-8bfb-3562a3e206df)
$ VBoxManage storageattach debian --storagectl "SATA Controller" \
--port 1 --device 0 --medium none
$ VBoxManage snapshot foo delete 8e2914fa-de59-4842-9391-3afac42e0125
0%...FAILED
Error: snapshot operation failed. Error message: Hard disk '../deb0.vdi' has
more than one child hard disk (2)
Huh? OK, I say it again: the VM's setup was seriously braindamaged, so maybe VirtualBox got a little confused. A somehow related ticket suggested to revert the snapshot to a current state. Did that and went on to detach the disks from the VM but now things got a bit out of hand:
$ VBoxManage snapshot 3c57773a-de6a-4714-9149-407a98f85ae7 restorecurrent
$ VBoxManage showvminfo foo | grep SCSI
SCSI Controller (0, 0): ../foo/Snapshots/{95000117-e5e0-46dc-bbbd-4929afd9b88c}.vdi
(UUID: 95000117-e5e0-46dc-bbbd-4929afd9b88c)
SCSI Controller (1, 0): ../foo/Snapshots/{f209322c-b784-4ec3-b0af-e0374444b349}.vdi
(UUID: f209322c-b784-4ec3-b0af-e0374444b349)
$ VBoxManage storageattach foo --storagectl "SCSI Controller" \
--port 0 --device 0 --medium none
$ VBoxManage storageattach foo --storagectl "SCSI Controller" \
--port 1 --device 0 --medium none
$ VBoxManage showvminfo foo | grep ^SCSI
SCSI Controller (1, 0): ../foo/Snapshots/{f209322c-b784-4ec3-b0af-e0374444b349}.vdi
(UUID: f209322c-b784-4ec3-b0af-e0374444b349)
Huh? I just detached the disk from the VM, how comes it's still attached? Shortly after, both disks were attached to the SCSI controller again. This did not look right, so I felt like cheating a bit:
$ pkill VBoxSVC $ mv ../Machines/foo/Snapshots/* ~/trash/Meanwhile, I had 4 (!) disks referring to 03b1afd9-4ce4-4e42-9347-226b55cba657 now, I wonder why:
$ VBoxManage list hdds | egrep '^(UUID|Parent)' [...] UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657 Parent UUID: base UUID: bc3b45a9-db44-41a4-822d-52987f2734c8 Parent UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657 UUID: 06280b86-8389-40c4-8bfb-3562a3e206df Parent UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657 UUID: 95000117-e5e0-46dc-bbbd-4929afd9b88c Parent UUID: 03b1afd9-4ce4-4e42-9347-226b55cba657 $ VBoxManage closemedium disk bc3b45a9-db44-41a4-822d-52987f2734c8 $ VBoxManage closemedium disk 06280b86-8389-40c4-8bfb-3562a3e206df $ VBoxManage closemedium disk 95000117-e5e0-46dc-bbbd-4929afd9b88cAlso, I removed all the storage controllers attached to VM foo:
$ VBoxManage storagectl foo --name "IDE Controller" --remove $ VBoxManage storagectl foo --name "SATA Controller" --remove $ VBoxManage storagectl foo --name "SCSI Controller" --remove $ VBoxManage storagectl foo --name "SAS Controller" --removeThis did the trick, apparently:
$ VBoxManage snapshot foo delete 8e2914fa-de59-4842-9391-3afac42e0125 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% $ VBoxManage unregistervm foo --deleteRe-attaching the disks to the other VM, and we're done:
$ VBoxManage storageattach debian --storagectl "SATA Controller" \
--port 0 --device 0 --type hdd --medium ../debian/deb0.vdi
$ VBoxManage storageattach debian --storagectl "SATA Controller" \
--port 1 --device 0 --type hdd --medium ../debian/deb1.vdi
patchadd aborted with:
Running patchadd Validating patches... Loading patches installed on the system... Done! Loading patches requested to install. [...] Checking patches that you specified for installation. Done! Unable to install patch. Not enough space in /var/run to copy overlay objects. 401MB needed, 220MB available. Failed (exit code 1)Well, this Sun Enterprise 250 only has 768 MB memory, not too much in these days. Let's add some virtual memory then:
# mkfile 1g /var/tmp/swap.tmp # swap -a /var/tmp/swap.tmp /var/tmp/swap.tmp: Invalid operation for this filesystem typeOh, right - we're on ZFS already. Let's try again:
# rm /var/tmp/swap.tmp # zfs create -V 1gb rpool/tmpswap # swap -a /dev/zvol/dsk/rpool/tmpswap # df -h /var/run Filesystem size used avail capacity Mounted on swap 1.4G 107M 1.3G 8% /var/runNow we should be good to go :-)
# df -h | grep -c /var/run 991
yum upgrade failed due to insufficient diskspace and yum exited with:
/usr/sbin/build-locale-archive: cannot add to locale archive: No such file or directory
could not write to ts_done file: [Errno 28] No space left on device
[...]
Error unpacking rpm package imsettings-libs-1.2.6-1.fc16.x86_64
error: gtk2-2.24.8-2.fc16.x86_64: install failed
error: unpacking of archive failed on file \
/usr/lib64/libimsettings.so.5.2.0;4ed44d97: cpio: write
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/yum/rpmtrans.py", line 444, in callback
self._instCloseFile( bytes, total, h )
File "/usr/lib/python2.7/site-packages/yum/rpmtrans.py", line 507, in _instCloseFile
self._scriptout(txmbr.po)
File "/usr/lib/python2.7/site-packages/yum/rpmtrans.py", line 246, in _scriptout
self.base.history.log_scriptlet_output(data, msgs)
File "/usr/lib/python2.7/site-packages/yum/history.py", line 871, in log_scriptlet_output
self._commit()
File "/usr/lib/python2.7/site-packages/yum/history.py", line 640, in _commit
return self._conn.commit()
sqlite3.OperationalError: database or disk is full
error: python callback > failed, aborting!
OK, no big deal. Just resized the root partition so that enough space is available now and try again:
$ yum upgrade [...] There are unfinished transactions remaining. You might consider running \ yum-complete-transaction first to finish them. [...] Error: Protected multilib versions: glibc-2.14.90-19.x86_64 != glibc-2.14.90-14.i686This didn't go so well. Let's try
yum-complete-transaction then, as suggested:
$ yum-complete-transaction Loaded plugins: langpacks, presto, refresh-packagekit There are 1 outstanding transactions to complete. Finishing the most recent one The remaining transaction had 87 elements left to run Package glibc-common-2.14.90-19.x86_64 already installed and latest version [...] --> Processing Dependency: libc.so.6()(64bit) for package: elfutils-0.152-1.fc16.x86_64 --> Processing Dependency: /bin/sh for package: kernel-3.1.2-1.fc16.x86_64 [....]This goes on for quite a while, hours even. I went to bed at this time, only to see the next morning that
yum got killed by the out-of-memory killer:
Out of memory: Kill process 1457 (yum-complete-tr) score 782 or sacrifice child Killed process 1457 (yum-complete-tr) total-vm:1643616kB, anon-rss:830884kB, file-rss:0kBThe VM has 1 GB RAM and 512 MB swap - not too much, but certainly enough for doing an upgrade, I assumed. OK, so how to go on from here? With
yum-complete-transaction failing, I decided to cleanup any old transactions and start from scratch:
$ yum-complete-transaction --cleanup-only Cleaning up unfinished transaction journals $ yum-complete-transaction No unfinished transactions left.But now the upgrade would stop with:
$ yum upgrade [...] Error: Protected multilib versions: glibc-2.14.90-19.x86_64 != glibc-2.14.90-14.i686Using
--setopt=protected_multilib=false (and --skip-broken) brought us only little further:
$ yum upgrade --setopt=protected_multilib=false --skip-broken [...] Transaction Check Error: file /usr/share/doc/glibc-2.14.90/NEWS conflicts between attempted installs of glibc-2.14.90-14.i686 and glibc-2.14.90-19.x86_64Moving
/usr/share/doc/glibc-2.14.90/NEWS out of the way did not help in this case. What did help was to "remove" the conflicting package from the package database. Of course, we could not really delete glibc, since it's needed for pretty much everything:
$ rpm --erase --nodeps --noscripts --justdb glibc-2.14.90-14.x86_64 $ yum upgrade --setopt=protected_multilib=false --skip-broken [...]This went through successfully and the system is now properly updated and even survived a reboot. Just in case that it's still not clear from these notes: I find it unacceptable that
yum is having such a hard time finding out how to do the Right ThingTM after a failed transaction. And yes, I've been using apt-get for years now - never had anything remotely similar to this mess. Incredible, I cannot understand how people can work with that. I mean, really work. I'm using Fedora only for playing around and while I really like some of the approaches Fedora is going for, this yum crap is a major show stopper for me to ever adopt any rpm-based distribution. I'd rather do ports :-\
$ yum check
Loaded plugins: changelog, langpacks, presto, refresh-packagekit
glibc-common-2.14.90-14.x86_64 has missing requires of glibc = ('0', '2.14.90', '14')
glibc-common-2.14.90-19.x86_64 is a duplicate with glibc-common-2.14.90-14.x86_64
In my case, "package-cleanup --cleandupes" solved this one. Sigh...
VBoxManage controlvm <VM> keyboardputscancode 1d 38 54 <PRESS> <RELEASE> d4 b8 9dThe
PRESS and RELEASE values are derived from the scancodes: The PRESS value is the bare scancode, the RELEASE value is the PRESS value plus 0x80."s" (to Sync the filesystems), the scancode would be 0x1F. And 0x1F + 0x80 equals 9F, this would be the scancode for releasing the key. Putting this all together, sending sysrq-s to the virtual machine goes like this:
VBoxManage controlvm <VM> keyboardputscancode 1D 38 54 1F 9F D4 B8 9DNote: Be sure to set
kernel.sysrq = 1 in your Linux guest machine, so that sysrq-keycodes are actually honored by the guest.VBoxManage controlvm <VM> keyboardputscancode 1d 38 3bThis is the equivalent to
Ctrl-Alt-F1 and would switch to the first terminal. Iterate 0x3b up to 0x42 to switch up to Ctrl-Alt-F8.
bash completion would not work any more in this DomU:
# tail -f /var<TAB>-bash: /dev/fd/62: No such file or directory -bash: /dev/fd/60: No such file or directoryWorkaround:
# sudo ln -s /proc/self/fd /dev/fd...or just install
udev, although this package was not needed before the upgrade. Oh, there's a bug report for this one too.
$ yum install httpd php links mediawiki mediawiki-Cite $ grep ^Alias /etc/httpd/conf.d/mediawiki.conf Alias /wiki/skins /usr/share/mediawiki/skins $ cp -a /var/www/wiki/ /var/www/html/ $ systemctl enable httpd.service $ systemctl start httpd.serviceNote that we did not install a MySQL server here: I did not want to run yet another service in this small virtual machine.
http://fedora.local/wiki/ - be sure to choose SQLite for the database backend.mysql2sqlite.sh -u admin -p mw_wiki > wiki.sqlite.rawI could pipe the whole thing through
sqlite already but I had to alter the output a bit: my original database had $wgDBprefix set to "mw_" but somehow this parameter seems to be ignored when an SQLite database is used. So let's cut out the prefix from our preliminary dump whenever a table is created, indexed or inserted1) into:
sed -e '/[INDEX|INTO|TABLE] \"mw_/s/mw_//g' -i wiki.sqlite.rawNow we can generate our SQLite database as simple as:
sqlite wiki.sqlite < wiki.sqlite.rawPoint $wgDBname to this filename and off we go: the wiki should now be up & running with the original data visible. Yay ;-)
INSERT INTO text (old_id,old_text,old_flags) VALUES (NULL,... Database returned error "19: text.old_id may not be NULL".Hm, shouldn't
old_id be set to AUTOINCREMENT? Let's look at our wiki.sqlite.raw again:
CREATE TABLE "text" (
"old_id" int(10) NOT NULL ,
"old_text" mediumblob NOT NULL,
"old_flags" tinyblob NOT NULL,
PRIMARY KEY ("old_id")
);
Again: this is the output of mysql2sqlite and it looks pretty sane to me. But somehow old_id wasn't set to PRIMARY KEY (aka "AUTOINCREMENT") when parsed by sqlite (v3.7.7.1). When the "PRIMARY KEY" is moved right before the "NOT NULL" statement for old_id, it still would not recognize it. We also had to replace the "int(10)" with INTEGER and remove the superfluous space on the same line. Now it reads:
CREATE TABLE "text" ( "old_id" INTEGER PRIMARY KEY NOT NULL, "old_text" mediumblob NOT NULL, "old_flags" tinyblob NOT NULL );We have to modify all (19) occurences of
PRIMARY KEY in our wiki.sqlite.raw. Be sure to omit the INTEGER keyword when the field is declared varbinary.
With all that in order now, wiki.sqlite.raw can be fed into sqlite again. FWIW, this is what sqlite makes of the statement above:
$ sqlite3 data/wikidb.sqlite
sqlite> .schema text
CREATE TABLE text (
old_id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
old_text BLOB NOT NULL,
old_flags BLOB NOT NULL
);
Now we should be able to update pages and create articles. Phew, what a ride :-)$ php maintenance/dumpBackup.php --full --uploads --conf `pwd`/LocalSettings.php > wiki.xmlThen, in the VM again:
$ cd /var/www/html/wiki $ php /usr/share/mediawiki/maintenance/importDump.php wiki.xml $ php /usr/share/mediawiki/maintenance/rebuildrecentchanges.phpThis takes quite a lot of time - around 7 minutes for a 13MB
.xml dump. The resulting was written into the configured $wgDBname, or data/wiki.sqlite in our case. All pages were in place, only the MainPage was overwritten with its initial version. Going back one version with the page history revealed the most current version of the (imported) article.
What's up with the latest Growl update? Apparently it costs money now? Not that $1.99 for this useful piece of software were too much, but...no announcement about this change? Why not? Users are already upset about this change and I really fail to see why they did this w/o any prior notification./etc/resolv.conf has been equipped with a secodary nameserver entry - great! And nslookup works like a charm too, heh! But all the other useful tools are waiting for ages until they'll get a response from the backup server - why is that?
$ time ping eve eve is alive real 0m30.045s user 0m0.007s sys 0m0.018sOther than e.g.
nslookup, the normal applications have to use the the resolver(4) to get their name requests answered. Now, we could cheat and put our backup server before the faulty one, but let's see if we can tackle this from a different angle. resolv.conf(4) was most helpful, of course:
options Allows certain internal resolver variables to be modified. timeout:n / retrans:n Sets the amount of time the resolver will wait for a response from a remote name server before retrying the query by means of a different name server. Measured in seconds, the default is RES_TIMEOUT. SeeIn ourattempts:n / retry:n Sets the number of times the resolver will send a query to its name servers before giving up and returning an error to the calling application. The default is RES_DFLRETRY. See .
resolv.h (Solaris 10) we have :
$ egrep 'RES_TIMEOUT|RES_MAXRETRANS|RES_DFLRETRY' /usr/include/resolv.h #define RES_TIMEOUT 5 / min. seconds between retries / #define RES_MAXRETRANS 30 / only for resolv.conf/RES_OPTIONS / #define RES_DFLRETRY 2 / Default #/tries. /So, let's tweak those
options:
$ grep options /etc/resolv.conf options timeout:1 retry:1 $ time ping eve eve is alive real 0m7.794s user 0m0.007s sys 0m0.018sWhooha, not bad.
$ grep options /etc/resolv.conf options timeout:1 retry:0 $ time ping eve eve is alive real 0m2.100s user 0m0.007s sys 0m0.018sEven better. Of course, one has to realize that with zero retries the resolver will jump to the next nameserver on the first failure - so, if our backup server is a bit sleepy we won't get a reply at all. If you enable nscd, subsequent requests to the same name will be answered instantly:
$ sudo svcadm enable svc:/system/name-service-cache $ time ping eve eve is alive real 0m3.218s user 0m0.007s sys 0m0.018s $ time ping eve eve is alive real 0m0.198s user 0m0.007s sys 0m0.017s
Error 403 We're sorry, but we could not fulfill your request for /account/login.php on this server. You do not have permission to access this server. Your technical support key is: 43ae-fa75-17f4-e8c8 Please contact ... and be sure to provide the technical support key shown above and as much information as you can so we can resolve the problem.Well, I really needed to login so I contacted the support guys. Although they responded within minutes(!), they were not really sure why I do not have permission to access this server. Something about my useragent, but then it could be my IP address as well. After a few exchanges it became clear that it was really my useragent what's being blocked. As I've modified general.useragent.override this must've been catched by some of their blacklists. To be specific, the following string was blocked:
Mozilla/5.0 (X11; U; Linux; en-US; rv:1.0) Gecko/25250101
While the following allowed me to login:
Mozilla/5.0 (X11; U; Linux; en-US; rv:1.0) Gecko/20050316
Now, the only tow questions left open are:
mkdir schneierfacts && cd schneierfacts
f=1
while [ $f -lt 1610 ]; do
echo "fact: $f"
wget -q http://geekz.co.uk/schneierfacts/fact/"$f"
sleep 1
f=$((f+1))
done
grep 'p class="fact"' * | \
sed 's/.*fact\">//;s/<\/p>//;s/\"\;/\"/g' | \
sort -u > ../schneierfacts.txt
sed G ../schneierfacts.txt | sed 's/^$/%/' > ../schneierfacts
strfile -r ../schneierfacts
"../schneierfacts.dat" created
There were 1600 strings
Longest string: 24713 bytes
Shortest string: 142 bytes
With that in place, we can install our new fortune file:
sudo mkdir -p /usr/local/share/games/fortunes
sudo cp ../schneierfacts{,.dat} /usr/local/share/games/fortunes/
$ fortune schneierfacts
When Bruce Schneier does modulo arithmetic, there are no remainders. Ever.
Note: There are currently over 1600 facts, be kind when downloading the facts! (i.e. use sleep(1) after every wget(1) call.)
TCP: Peer 1.2.3.4:64259/51542 unexpectedly shrunk window \
4197231805:4197240525 (repaired)
It was a bit scarier back then when it read something like this:
TCP: Treason uncloaked! Peer 1.2.3.4:64259/51542 shrinks window \
3166327388:3166327393. Repaired.
The message has been modified in December 2008.
While there are quite a lot of posts and articles on this topic, a pretty good explanation can be found in commit 2ad4106: Clear stale pred_flags when snd_wnd changes.
> We are Wall Street. It's our job to make money. Whether it's a commodity, > stock, bond, or some hypothetical piece of fake paper, it doesn't matter. We > would trade baseball cards if it were profitable. I didn’t hear America > complaining when the market was roaring to 14,000 and everyone’s 401k > doubled every 3 years. Just like gambling, it’s not a problem until you lose. > I've never heard of anyone going to Gamblers Anonymous because they > won too much in Vegas....and so the leaflet from the financial traders goes on to explain why everything is just OK the way it is. Oh well, that's a relief. I was kinda worried, but not anymore...
127.0.0.1 - - [21/Oct/2011:18:59:02 -0700] "GET /announce?info_hash=.... \
HTTP/1.1" 404 142 "-" "rtorrent/0.8.6/0.12.6"
This happens every few minutes or so. It's not causing any trouble, but why does rtorrent connect to localhost? Someone at #rtorrent pointed out that it may be a tracker, resolving to localhost. And indeed, going through the trackerlist a popular tracker decided to resolve some of their servers to localhost. And they even explain why:
Because retarded ISPs and registrars like to hijack NXDOMAIN responses to display ads and crap. Also, if you are using a service like OpenDNS, you'll get their generic error response instead.Understandably :-)
localhost seems weird, so for now I'm just adding the tracker in question to /etc/hosts and point it to an unused private IP address to get rid of these bogus log entries.
Go for the tried and true path. Don't be risking your data on NoSQL databases.Another favourite:
As a result, NoSQL databases may only have partial or no sql support.No shit, Sherlock! :-)
# pkgutil -u CSWpkgutil Checking integrity of ../catalog.mirrors.usc.edu_pub_csw_unstable_sparc_5.10 with gpg. gpg: Signature made Wed Oct 05 12:32:42 2011 PDT using DSA key ID 9306CC77 gpg: Can't check signature: public key not found Bad signature detected in catalog!But the key had been imported already:
