5.8-C amd64 X200: Lock X after suspend.

Hi,

Got a good tips from OpenBSD.newbies mailing list. How to lock the machine after suspend. Ok, normally, if I didn't xlock my X session and put the machine under suspend mode (eg: close the lid), my session will be restored when the machine wakes. My session is exposed. So here's how to automatically lock the session when the machine goes into suspend mode.

1) Create a suspend file inside /etc/apm.
In my machine, there's no /etc/apm folder. So I need to create it first. Then create a suspend file inside it.

$ doas mkdir /etc/apm
$ doas vi /etc/apm/suspend

----- /etc/apm/suspend starts -----
#!/bin/sh
pkill -USR1 xidle
----- /etc/apm/suspend ends -----

Then I need to make this suspend executable.

$ doas chmod 744 /etc/apm/suspend

2) Get xidle running on start.
I edited my
.xsession file and add this text:
----- ~/.xsession starts -----
xidle &
----- ~/.xsession ends -----

Then I run the xidle program.

$ xidle &

So basically when I close my machine's lid, suspend will trigger xidle to lock the machine. Nice stuff.

Reference:
http://www.mail-archive.com/openbsd-newbies@sfobug.theapt.org/msg00043.html

5.8-C amd64 X200: Bye sudo, hi doas.

Hey,

Done updating, rebuilding the userland and following the.. err.. "Following -current" guide, now to reboot.

$ sudo reboot
ksh: sudo: not found

Oh. Yeah. I forgot. sudo is old news. Now it's doas time.

man doas
man doas.conf

Now, after all the setups, all I have to do to reboot is:

$ doas reboot

http://www.tedunangst.com/flak/post/out-with-the-old-in-with-the-less

http://www.tedunangst.com/flak/post/doas

Now it's just a matter of learning new habit. Later.

5.8-C amd64 X200: httpd error after upgrading snapshot.

Hi,

I downloaded the 29th September's SNAPSHOT and installed it successfully. But, after I rebooted, this error greeted me:

httpd(xxxx): syscall 5

The "xxxx" is replaced by bunch of numbers. Ouch. Searching the net about this but found no answer so far. I'm guessing that this is related to php, php-fpm or something. But I'm not sure.

UPDATE 30/09/2015:
Ok I asked misc regarding this and Ted Unangst has given the answer:

"The latest snapshots include a bunch of tame() calls in userland programs, but some of them were added optimistically. httpd is trying to do something it's not yet permitted to do.

For now, please report such errors.

If you need a working version, the diffs aren't committed yet, so you can rebuild httpd from source and it should work fine."


http://www.mail-archive.com/misc@openbsd.org/msg141426.html

Now, who said that the devs are bunch of man-eating-flame-throwing monster? As long as we search for answer first before asking (to see if it's already been asked and/or solved), and provide sufficient details (dmesg, related .conf files etc) when asking, you will get informative answers.

Ok. So it's basically new stuff in the httpd's snapshot. And to get a working httpd, I need to rebuild it. I've done port installation stuff but rebuilding a base program? I've never done this. But this is a good learning process. So I use the official guide:

http://www.openbsd.org/faq/faq5.html#Bld

I follow the "Following -current" guide. Then build the userland (I didn't build the kernel). It took some time. When it's done, I rebooted and httpd is working again! Yeah!

I noticed there's changes about php-fpm so I go through the Following -current page:

http://www.openbsd.org/faq/current.html#20150918

The previously named php_fpm rc script has been renamed according to PHP's version installed. So I edited my /etc/rc.conf.local.

----- /etc/rc.conf.local starts -----
pkg_scripts=php56_fpm
----- /etc/rc.conf.local ends -----

Just to be sure, I pkg_delete php-fpm then reinstall it. Reboot.

All is ok now. Thanks to Ted Unangst and all the people in misc@OpenBSD.

I think there's a way to just rebuild httpd, without rebuilding all userland. I'm searching for info on this.

Update 1st October 2015:

Stuart Henderson @misc has given a tip on how to update just the httpd.

$ cd /usr/src/usr.sbin/httpd
$ cvs up -PdA
$ make obj && make depend && make
$ su root -c 'make install'

 http://article.gmane.org/gmane.os.openbsd.misc/225370

Nice!. Learning something new everyday. Later.

5.8-C amd64 X200: Drupal 7 Multisite.

Hey,

Why multisite? I read quite a bit of discouragement about this topic. Well, this is a local installation and it is a development (or hope to be) machine so I will (or might) be doing multiple sites. Hence the need.

My reference will be this site:

https://www.drupal.org/documentation/install/multi-site

You might need to refer to my previous posts as I might not be duplicating what is unnecessary here.

1) Preparing the site.
My default drupal site is drupal.example.com. So, I think I want to create another site called drupal2.example.com. I create a folder inside Drupal's sites folder.

$ cd /var/www/htdocs/drupal7/sites/
$ sudo mkdir drupal2.example.com

Along with that, I need to create a files folder inside my new drupal2's folder.

$ sudo mkdir -pm 777 drupal2.example.com/files

The files will need to be fully writeable as installation will gave error or not able to write inside that folder.

Folder creation done, now to set up appropriate files. Inside sites folder, there a file named example.sites.php. For a single-site.. err.. site, no need to touch this file but as I'm trying to create a multisite.. err.. site now, I need to edit this file. First I need to copy this file as sites.php file.

$ sudo cp example.sites.php sites.php

Now to edit this, adding this text at the bottom (bolded):

----- sites.php starts -----
<?php
* text snipped *

$sites['drupal2.example.com'] = 'example.com';
?>
----- sites.php ends -----

Yeah you read it right, I also included the closing tag for php as there's none there. Then I need to copy default.settings.php and put it as settings.php inside drupal2.example.com folder.

$ sudo cp sites/default/default.settings.php sites/drupal2.example.com/settings.php

Now to edit this file. I need to find and edit the $databases = array () occurances and change it to this.

----- drupal2 settings.php starts -----
$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => 'drupal2',
      'username' => 'drupal',
      'password' => 'password',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'pgsql',
      'prefix' => '',
    ),
  ),
);
----- drupal2 settings.php ends -----

Remember this. I'm using PostgreSQL. This file is to set up my currently-non-existant new drupal2.example.com site's database. This part of the setup is complete.

2) Set up the database.
The command for PostgreSQL is:

$ createdb -U drupal -E UTF8 drupal2

For clarification, refer to my previous post about Drupal 7's installation. Basically I'm creating a black database using the "drupal" username with UTF8 encoding (needed!) and the name of that database is "drupal2". Make sure that the previous settings.php is configured according to this informations.

3) Set up the (local) domain.
I edited the /etc/hosts file.

----- /etc/hosts starts -----
127.0.0.1 drupal2.example.com
----- /etc/hosts ends -----

There's also other entries inside that file but I'm just showing the changes.

4) Configure HTTPd.
I edited the /etc/httpd.conf and inserted these text.

----- /etc/httpd.conf starts -----
server "juadah.example.com" {
        listen on $ext_addr port 80

        directory {
                index "index.php"
        }

        location "*.php*" {
                fastcgi socket "/run/php-fpm.sock"
        }

        root "/htdocs/drupal7"
}
----- /etc/https.conf ends -----

This is just a basic configuration. This should be it. Now to install the new site. I open up my browser, and type the new URL drupal2.example.com.

PDOException: SQLSTATE[42P01]:

Wha..?. I received errors instead talking about some PDO stuff. Ouch. After searching for a while, I found the answer. Wrong URL. The correct one for installation is:

drupal2.example.com/install.php

Then the installation went through. I got 2 warning when installing. 1 is for the files directory not writeable (hence the steps above) and the other one is about the unicode issue, refer my previous post as I need to patch the Drupal installation again because, hey, I'm following -CURRENT. Later.

5.8-C X200 amd64: lib.c.81 not found after upgrading -current, and bunch of others.

Okay, so here I was, updating my -current system. Because, yeah, it's been a while. Fired up my ftp, grab the bsd*, *tgz and all, the usual stuff. Upgraded my system, done changing timezone and sysmerge. All is good. So I upgraded my packages. This is what happened.

Update candidates: xz-5.2.1 -> xz-5.2.1
Can't install xz-5.2.1 because of libraries
|library c.81.0 not found
| /usr/lib/libc.so.78.1 (system): bad major
| /usr/lib/libc.so.79.0 (system): bad major
| /usr/lib/libc.so.80.0 (system): bad major
| /usr/lib/libc.so.80.1 (system): bad major
| /usr/lib/libc.so.82.0 (system): bad major

Ack!. Then I this bunch of warnings like:

Can't install pkg_name because of libraries

Ok. Not bunch. But a lot. I'm guessing that this is about new version of libraries. So, after searching for answers, I found this:

http://comments.gmane.org/gmane.os.openbsd.misc/224817

Whew I'm grateful this is not because of some mistakes I made while upgrading. I even did another upgrade just to make sure. Yeah, so I need to wait for a few days before upgrading my packages. Later.

5.8-S amd64 X200: httpd Virtual Host.

Hi,

I've been having headache trying to solve the Virtual Hosting issue when using OpenBSD's new httpd (starting from 5.7) included in the base. After fairly quite a lot a trial and errors (mostly errors) and nearly downloading nginx today, I finally got the Virtual Host working now.

I really like the concept of OpenBSD's new httpd. Simple configuration, the devs are keeping the code simple and it's in the base. I also got Drupal 7 working fine (except for clean url, which is minor as this is for developing, not production) and I'm having fun learning Drupal here. But so far, I only managed to get 1 site working at a time. That means, I need to reconfigure my /etc/httpd.conf every time I want to change the website I want to work on. If I only want to work on a single site, this would not pose a problem. But I have more than 1 website I want to work on, so this is tiring me down.

I know that the httpd is chrooted by default, but I didn't know how to configure it properly until now. Well "properly" is not as "perfect" but more to "got it to work" kind of saying. So please correct me if you find anything that's wrong here. So here it goes.

My scenario, I'm working in 1 Drupal 7 site, then 1 another html/php site. The directory is as below:

/var/www/htdocs (the /var/www is the chroot directory)
/var/www/htdocs/drupal7 (my drupal dev directory, the default as installed)
/var/www/htdocs/karl (my html/php dev site)

For Drupal 7 installations and configurations, you can check my previous post. Now here's my /etc/httpd.conf.

---- /etc/httpd.conf start ----

# Macros
ext_addr="*"

# Server
server "default" {
    listen on $ext_addr port 80

    directory {
        auto index
    }

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }

    location "/cgi-bin/*" {
        fastcgi
        root "/"
    }

}

---- /etc/httpd.conf end ----

Now that's for the default site. I noticed that if I change the upper part to:

server "www.example.com" {
    listen on $ext_addr port 80
    alias "example.com"

Then if I just type "example.com" in my browser, it will display my local site's main page instead of the internet's site. Take note that it's easier to use "Private Window" (Firefox) or "Incognito Window" (Chrome) for testing purpose. I also set the index to be created automatically because I don't want to create any site inside the root "/htdocs" directory and this is just a local development machine. Now for the Virtual Host setting inside /etc/httpd.conf.

---- /etc/httpd.conf continues ----

# virtual server for Drupal
server "drupal.example.com" {
    listen on $ext_addr port 80

    directory {
        index "index.php"
    }

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }

    root "/htdocs/drupal7"

}

# virtual server for Karl
server "karl.example.com" {
    listen on $ext_addr port 80

    location "*.php*" {
        fastcgi socket "/run/php-fpm.sock"
    }

    root "/htdocs/karl"

}

types {
    includes "/usr/share/misc/mime.types"
}

---- /etc/httpd.conf ends ----

Now this is the simplest working form of my /etc/httpd.conf. On httpd side, this should be ok. Now for the important part, making the Virtual Host part work. As httpd works in chroot by default, it will only access files inside /var/www for safety reason. So I need to create an etc directory inside /var/www.

# mkdir /var/www/etc

Then I need to copy /etc/hosts and /etc/resolv.conf into /var/www/etcb.

# cp /etc/hosts /var/www/etc
# cp /etc/resolv.conf /var/www/etc

This is the content of both files:

---- /var/www/etc/hosts start ----

127.0.0.1    localhost    www.example.com
::1    localhost    www.example.com

---- /var/www/etc/hosts end ----

---- /var/www/etc/resolv.conf start ----

# Generated by em0 dhclient
search Home
nameserver 127.0.0.1
lookup file bind

---- /var/www/etc/resolv.conf end ----

Ok. I was thinking that to make Virtual Host using httpd works, I need to edit that /var/www/etc/hosts file, as that is the chroot directory. I was wrong. I didn't manage to get the Virtual Host working by editing that file. It was the /etc/hosts file that needs editing. Here's mine.

---- /etc/hosts start ----

127.0.0.1    localhost    www.example.com
127.0.0.1    drupal.example.com
127.0.0.1    karl.example.com
::1    localhost    www.example.com

---- /etc/hosts end ----

I only use 2 Virtual Hosts as of now, but I'm guessing that more can be set up with appropriate configuration changes. So now I restarted the httpd.

# sudo /etc/rc.d/httpd restart

Open up my browser, typed all 3 urls:

www.example.com
drupal.example.com
karl.example.com

and all open up the appropriate pages. I'm loving this! Now this leave only 1 more minor thing to be done, the Clean URL. But like I've said, it's only a minor thing. Later.