Posts Tagged ‘Linux’

hostapd can not find the wlan interface but interface is ready

Wednesday, February 25th, 2015

Have you ever got an error when using hostapd complaining a network interface not be found but its actually there and ready? You probably have a space at the end of the line “interface”. Hostapd does not work when having a space in that line (and probably in other lines as well) in /etc/hostapd/hostapd.conf.

ap:/etc/hostapd# cat -vet hostapd.conf|grep ^interface
interface=wlp0s29f7u7 $
ap:/etc/hostapd#

This shows that there is a space at the lines end. Remove it and it will work as expected. Remove it and it works. If it does not work you probably have an error in another layer of your WLAN setup.

Epson scanners on Linux systems

Tuesday, January 11th, 2011

I’ve got a Epson Perfection 1260 Photo scanner.

Fedora like other distributions such as OpenSuse are recognizing the device since a long long time. The back end chosen for the device is plustek.

Unfortunately when using the default configuration one experience very strange effects with colours. The left and the right 50% of the picture have a colored background, even when scanning a empty page.

I had this problem with OpenSUSE since years and still got it with Fedora 1x. Since I only need the scanner for my yearly income tax declaration, I always forget about what I needed to change.

That’s what is needed to change:

Solution

[root@bond ~]# diff /etc/sane.d/plustek.conf.orig /etc/sane.d/plustek.conf
100c100
< option altCalibration 0
---
> option altCalibration 1
[root@bond ~]# 

Since I do not have any other scanners I do not know if this is a bug specifically to this type of scanners, or if it is a general bug.

Using different search engines, the web does not disclose some solutions. That is one of the reasons why I’m blogging about it. The other reason is to find other people with the same problem.

At the end of the day, I’ll try to find out if this is a general bug of the Sane back end, or just specific to some Epson scanners. If it is specific to some Epson scanners, it may be worth to create a new specific back end for those scanners affected.

Having fun? Now I have, my stuff is successfully scanned.

Usability Fedora vs Windows

Tuesday, November 30th, 2010

I’m writing this post sitting in a train, connected to the internet via UMTS. The device is a Huawai E220 HSDPA modem connected via USB. Guess who is the winner?

Procedure to get the device running on Fedora (first time usage):

  • Plug in the device on any USB port
  • Enter the PIN in the pop-up
  • Enjoy mobile Internet connection

Steps: 3
Time: approx. 5sec.

Procedure on Windows XP (first time usage):

  • Decide on what USB port you will plug in the device an memorize it, because subsequently it will only work on that USB port
  • Plug in the device
  • A virtual CDROM drive gets mounted, a window with some drivers is appearing
  • Install the driver
  • reboot your notebook
  • Finding and starting the previously installed software
  • Getting a pop-up asking for the PIN
  • Enjoy mobile Internet connection

Steps: 8
Time: approx 10min

[update]
Procedure on Windows 7 (first time usage):

  • Decide on what USB port you will plug in the device an memorize it, because subsequently it will only work on that USB port
  • Plug in the device
  • A virtual CDROM drive gets mounted, a window with some drivers is appearing
  • When autorun.inf is enabled, the driver installs automatically (on enterprise systems mostly disabled). if not enabled, read some documentation what to do
  • Finding and starting the previously installed software
  • Getting a pop-up asking for the PIN
  • Enjoy mobile Internet connection

Steps: 7
Time: Between 5min and 30min (depending on your Windows 7 knowledge)
[/update]

For the subsequent usage on Fedora proceed as it is the first time usage.

On Windows (XP and 7) you need to remember which port you plugged in the device when you installed it. Otherwise you need to uninstall the drivers, reboot and install the drivers again and reboot again. [update]On Windows 7 you do not need a reboot.[/update]

Having fun? With Fedora yes :-) With Windows? Not really…

Deploying RHEL as ESX guests – Kickstarting or using ESX templates?

Wednesday, October 20th, 2010

Some time ago I asked my self the question if it is better to kickstart systems or working with ESX templates when deploying RHEL as ESX guests. I also had some discussions with friends working in the same industry. I tried it and came to the following conclusion:

Kickstart the systems is the way to go.

Pros:

  • Kickstarted Systems are already up-to-date after installation.
  • Proper SSH host keys. Using ESX templates ends up in having identical SSH host keys, from the security standpoint not usable, they need to be manually re-created.
  • Kickstarting means lean deployment, much less data needs to be transferred.
  • Very fast, kickstarted systems are deployed in ~3min instead of ~10min (depending on I/O and network performance).
  • Systems are being automatically registered @rhn or on a rhn-satellite with the help of cobbler snippets.
  • Better customization.

Cons:

  • The ESX template to used for kickstarting must have no disks configured, otherwise the whole nominal disk size is being transferred over the net.

When kickstarting virtual systems, only the data needed (the RPMs) is transferred. The best way is to have a “empty” ESX template, just with the network defined, but no disks. The reason for that is: ESX creates a checksum of the disk files, even if the disk is empty, the sparse disk files (in the case of “thin provisioning”) will be transferred over the net at its full nominal size.

When using ESX templates, after deploying, one needs to register the system manually and also manually update the system by invoking “yum -y update”. In contrary, kickstarted systems are always up to date automatically. To circumvent this fact, one needs to keep the templates up to date, it is a manual task which can not be automated easily.

Have fun!

RHN Inter-Satellite-Sync is kind of tricky and picky

Wednesday, May 5th, 2010

If you try to establish an ISS (Inter Satellite Sync) between two RHN Satellites, do not fully trust the documentation. A slave Satellite must be named by a hostname (IP is not enough) and must have an A and a PTR DNS record or have an /etc/hosts entry. Check it before restarting the satellite by issuing rhn-satellite restart. The check is simply done by entering gethostip rhn.example.com and getent hosts <IP-address> on the commandline.

When Quoting the documentaion at Red Hats web site: http://www.redhat.com/docs/en-US/Red_Hat_Network_Satellite/5.3/Installation_Guide/html/s2-sync-iss-config-master.html: allowed_iss_slaves=rhn.example.com means: A hostname, not just an IP. It is not clearly stated what kind of quality such an entry needs to have.

HTH….

Have fun!