よく参考画像がニュース映像やら記事やらで示されていて「※画像はイメージです。」と書かれているんだが、そりゃ「画像」なら「イメージ」だろ！同語反復じゃねーか！！と思うのだが、もっとまともな言い方はないのかな。
英語圏でも同じような書かれ方をしてるんだろうか。「This image is an imaginary image.」？？
リンク
2014年10月25日 in
未分類 | tags:
画像はイメージです。 |
No Comments
Gmailで自身を宛先に含むメールを表示する際に、サーバを経由して実際に届いたメールではなく、「送信済メール」に保存されているメールが表示されてしまう。
サーバ経由での配信状況の情報や、メーリングリストへの投稿の場合などは自身のメールについた通し番号を参照したいこともあるのだが。
何か設定があるんだっけ？
Gmailのヘルプ（↓）には自動的にアーカイブされるとあるが、ここに送信メールは表示されるが、受信されたメールは見当たらない…。
- メーリング リスト宛に送信したメールが受信トレイに表示されない – Gmail ヘルプ
- Gmail では、自分が登録しているメーリング リスト宛に送信したメールは、整理する手間を省くために、自動的に受信トレイをスキップしてアーカイブされます。ただし、このメールに他のユーザーが返信した場合や、エラーによりメールを送信できなかった場合は、メールは受信トレイに表示されます。メールを確認するには、[送信済みメール] や [すべてのメール] を探してください。
あー、2011年にも同じような記事を書いていたんだった…。
その際には、SMTPをGmail以外にしてはとの話まで到達していたらしい。
2014年10月1日 in
未分類 | tags:
Gmail |
No Comments
パスワードの単なるランダム選択での自動生成用のスクリプト（あとで見たらTclスクリプトだった…）を置いているサーバが動作していなかったので、手元のWindowsで動かしていたXyzzyのlispスクリプトですぐにできるだろうと思っていたら、リスト操作も忘れ、関数定義も忘れで思いのほか手こずってしまった…。
(defun make-password (&optional (n 7))
(let
(res (base "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_"))
(dotimes (i n)
(setq res (append res (list (char base (random (length base)))))))
(coerce res 'string)))もっといい組み方もあるんでしょうけど。
使用例
(make-password 7)
"PMu7xrX"
リンク
2014年8月18日 in
未分類 | tags:
xyzzy,
パスワード |
No Comments
（「VirtualBoxに苦戦」の続き）
VirtualBoxを動作させるのWindows版。
Linux版のVirtualBoxも起動できなかったが、Windows版のVirtualBoxでもリモートマシンの起動ができず、E_FALL (0x80004005)/Machine/IMachineのエラーが発生する。
ホスト側のWindowsが64bit版だからかとか、また検索するとE_FALL/Machineでのエラーが発生する際には「VT-x/AMD-xの仮想化を外せ」とか「BIOSのブート設定を見直せ」とかアドバイスに従って、いろいろチェックしてVirtualBoxの設定をいろいろ変えたりとしていたのだが効果がない。
結局は、ウィルスバスターとの相性か何かが悪さをしているようで、ウィルスバスターが動作しているとVirtualBoxは起動できてもリモートマシンの起動時に（おそらくホスト側との何かの共有設定が）引っかかるようだった。このため、WindowsでVirtualBoxを起動する際には、いったんウィルスバスターを終了しておくことが必要になる。VirtualBoxの起動後には、ウィルスバスターを再起動していても問題ないようなのだが、これをするとウィルスバスターを起動し直すのを忘れがちになってしまう…。ウィルスバスター側での許可設定があるのかと探したのだが、ちょっと見当たらなかった（例外設定のファイル/フォルダで「スキャンや監視の対象から除外」というものに、VirtualBox.exeやらそれらしきフォルダやらを加えてみたが変化なかった）。動作を拒否した際のポップアップ表示などもなし。わかりにくい…。ウィルスバスターを起動した状態で、リアルタイムスキャンをオフにしたりもしたのだが、それでも変化なかった。
仮想環境側のLinuxの種類にもよるのかと、Ubuntuにしてみたり、CentOSを使ってみたりしても変化なし。さらに、単にOSが未インストールの新規マシンをVirtualBox側に追加した場合でも、ウィルスバスターが動作していると起動できなかった。OS以前の問題らしい。
また、VirtualBoxが起動できてもできなくても、次のようなSynergy絡みのエラーが出ていることに気付いた。これも悪さをしているのか？？
VBoxHeadless: supR3HardenedMonitor_NtCreateSection: Not a trusted location: '\Device\HarddiskVolume2\Program Files\Synergy\synwinhk.dll' (fImage=1 fExecMap=1 fExecProt=1)
⇒で、Synergyもアンインストールしてみましたが、変化ありませんでしたわ…。
[追記：2014/8/13]
ウィルスバスターのサポートにも不具合の問い合わせをしていろいろ試していたのだが、結局は使用していたVirtualBoxのそのバージョン（Ver.4.3.14）の挙動が怪しいとの指摘で、教えて貰ったVirtualBoxの利用者フォーラム（↓）を眺めてみた。そうすると、Oracleから新バージョン（Ver.4.3.15）のVirtualBox（サードテストバージョン？）がリリースされているとのことで、そちらで試すとウィルスバスター稼働時でも仮想環境の起動ができた…。長かった…。
（※どちらも略すとVBなんだな…）
（Windows版での対応は⇒VirtualBoxに苦戦 (2)）
MVCを試そうとしてどうにもしっくりこないCakePHPにちょっと見切りをつけ、やっと記法にもなじんできたRubyでということで、本丸的な「Ruby on Rails」を試すことに。
参考本で、VirtualBoxで動かすようにしていたので真似てそちらを試そうとしたら、長き道のりの始まりだった…。
CentOS-6.5 x86_64の環境（↓）に：
$ cat /etc/issue; uname -a; cat /proc/cpuinfo | grep flags | uniq
CentOS release 6.5 (Final)
Kernel \r on an \m
Linux mibai.tec.u-ryukyu.ac.jp 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 21:14:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts tpr_shadow
下記リンクからCentOS-6 AMD64用のVirtualBoxを入手し、インストール：
これはこれで動作するようなんだが、Vagrantでのprovisionがうまくいかない：
$ vagrant up --provision
Bringing machine 'default' up with 'virtualbox' provider...
[default] Clearing any previously set forwarded ports...
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] -- 3000 => 4000 (adapter 1)
[default] Running 'pre-boot' VM customizations...
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Machine booted and ready!
[default] Mounting shared folders...
[default] -- /vagrant
[default] Running provisioner: shell...
[default] Running: inline script
Loaded plugins: fastestmirror, versionlock
Loading mirror speeds from cached hostfile
* base: centos.mirror.secureax.com
* epel: mirrors.hust.edu.cn
* extras: centos.mirror.secureax.com
* updates: mirror.neu.edu.cn
Setting up Update Process
Resolving Dependencies
There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.
--> Running transaction check
---> Package audit.x86_64 0:2.2-2.el6 will be updated
---> Package audit.x86_64 0:2.2-4.el6_5 will be an update
---> Package audit-libs.x86_64 0:2.2-2.el6 will be updated
...
---> Package python-libs.x86_64 0:2.6.6-52.el6 will be an update
---> Package selinux-policy.noarch 0:3.7.19-231.el6 will be updated
---> Package selinux-policy.noarch 0:3.7.19-231.el6_5.3 will be an update
---> Package selinux-policy-targeted.noarch 0:3.7.19-231.el6 will be updated
---> Package selinux-policy-targeted.noarch 0:3.7.19-231.el6_5.3 will be an update
---> Package subversion.x86_64 0:1.6.11-9.el6_4 will be updated
---> Package subversion.x86_64 0:1.6.11-10.el6_5 will be an update
---> Package upstart.x86_64 0:0.6.5-12.el6_4.1 will be updated
---> Package upstart.x86_64 0:0.6.5-13.el6_5.3 will be an update
---> Package util-linux-ng.x86_64 0:2.17.2-12.14.el6 will be updated
---> Package util-linux-ng.x86_64 0:2.17.2-12.14.el6_5 will be an update
---> Package yum-plugin-fastestmirror.noarch 0:1.1.30-14.el6 will be updated
---> Package yum-plugin-fastestmirror.noarch 0:1.1.30-17.el6_5 will be an update
---> Package yum-plugin-versionlock.noarch 0:1.1.30-14.el6 will be updated
---> Package yum-plugin-versionlock.noarch 0:1.1.30-17.el6_5 will be an update
---> Package yum-utils.noarch 0:1.1.30-14.el6 will be updated
---> Package yum-utils.noarch 0:1.1.30-17.el6_5 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository
Size
================================================================================
Updating:
audit x86_64 2.2-4.el6_5 updates 225 k
audit-libs x86_64 2.2-4.el6_5 updates 60 k
...
selinux-policy noarch 3.7.19-231.el6_5.3 updates 825 k
selinux-policy-targeted noarch 3.7.19-231.el6_5.3 updates 2.8 M
subversion x86_64 1.6.11-10.el6_5 updates 2.3 M
upstart x86_64 0.6.5-13.el6_5.3 updates 177 k
util-linux-ng x86_64 2.17.2-12.14.el6_5 updates 1.5 M
yum-plugin-fastestmirror noarch 1.1.30-17.el6_5 updates 28 k
yum-plugin-versionlock noarch 1.1.30-17.el6_5 updates 28 k
yum-utils noarch 1.1.30-17.el6_5 updates 102 k
Transaction Summary
================================================================================
Upgrade 48 Package(s)
Total size: 35 M
Total download size: 157 k
Downloading Packages:
--------------------------------------------------------------------------------
Total 18 kB/s | 157 kB 00:08
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.
** Found 4 pre-existing rpmdb problem(s), 'yum check' output follows:
glibc-2.12-1.132.el6_5.2.x86_64 is a duplicate with glibc-2.12-1.132.el6.x86_64
glibc-common-2.12-1.132.el6_5.2.x86_64 is a duplicate with glibc-common-2.12-1.132.el6.x86_64
nss-softokn-freebl-3.14.3-10.el6_5.x86_64 is a duplicate with nss-softokn-freebl-3.14.3-9.el6.x86_64
tzdata-2014e-1.el6.noarch is a duplicate with tzdata-2013i-1.el6.noarch
Updating : grep-2.6.3-4.el6_5.1.x86_64 1/96
Updating : coreutils-8.4-31.el6_5.2.x86_64 2/96
Updating : coreutils-libs-8.4-31.el6_5.2.x86_64 3/96
Updating : krb5-libs-1.10.3-15.el6_5.1.x86_64 4/96
...
Updating : glibc-devel-2.12-1.132.el6_5.2.x86_64 33/96
Updating : subversion-1.6.11-10.el6_5.x86_64 34/96
Updating : mdadm-3.2.6-7.el6_5.2.x86_64 35/96
Updating : 2:postfix-2.6.6-6.el6_5.x86_64 36/96
Updating : 1:nfs-utils-1.2.3-39.el6_5.3.x86_64 37/96
Updating : selinux-policy-targeted-3.7.19-231.el6_5.3.noarch 38/96[default] Running provisioner: shell...
SSH connection was refused! This usually happens if the VM failed to
boot properly. Some steps to try to fix this: First, try reloading your
VM with `vagrant reload`, since a simple restart sometimes fixes things.
If that doesn't work, destroy your VM and recreate it with a `vagrant destroy`
followed by a `vagrant up`. If that doesn't work, contact a Vagrant
maintainer (support channels listed on the website) for more assistance.何度やってもこのあたりで止まってしまう（始めのうちは、vagrant upの失敗後にもう一度試すとそのまま動作するので正しいのかと思っていたら、Vagrantの動作が変更になって、明示的に指定しないと再provisionをしないことになっていただけだった）。
SELinux関連で引っかかっているのか、ホスト側が64bit版だからなのかよくわからない。
って、確認するとSELinuxは「無効（Permissive）」になってたわ。
こちらは保留中。