Showing posts with label fedora. Show all posts
Showing posts with label fedora. Show all posts

Monday, November 10, 2014

OpenStack Nova Compute Cannot Launch Instance after Upgrade to Fedora 21

I updated my system to Fedora 21 beta and then found that I could not use OpenStack. Every effort to launch an instance failed:
libvirtError: operation failed: filter 'nova-no-nd-reflection' already exists with uuid 728f13cf-f1a9-4e0e-add7-357b93d052ee
Removing the openstack packages, clearing the data and reinstalling openstack did not help.

The problem seems to be an incompatibility  between nova-compute and the libvirt libraries.

Upgrading the libvirt libraries to rawhide did not help.

Finally, I used rpm to downgrade libvirt using downloaded packages from the fedora 20 repository, ignoring the dependency problems.
$ sudo rpm -U --oldpackage --nodeps libvirt*1.1.3*rpm
All seems well for now.



Tuesday, September 23, 2014

Experimenting with open source big data applications on a personal desktop

I decided to learn OpenStack, Hadoop, Elasticsearch and related open source software products using my quad core desktop. I had to raise the RAM to 16GB and add a 1 terabyte disk.

However, after the hardware upgrade, it has been remarkably simple to experiment and learn these tools using Fedora 20 repositories.

I am writing about my experiences in a monthly column in Open Source for You and will continue to post them on my site after a month or more of the publication.

I hope learning new tools is as effective as learning new languages to keep senility away after retirement :)

Saturday, August 23, 2014

Csound and x86_64 machines

I could not understand why Sugar TamTam activities wouldn't play any sound on x86_64 even though the problem seemed resolved! It took a while to realize that the problem was with x86_64 architecture. I could get the sound to play on an i686 virtual machine.

Thanks to realtime Csound programming using Python, I could trace the fault. The issue is illustrated by the following code in csoundSession.py:

        if csnd.csoundGetSizeOfMYFLT() == 8:
            pfields = csnd.doubleArray(n)
        else:
            pfields = csnd.floatArray(n)
The csound client code in Python and C used by tamtam activities assumes a float array.

The following line in csound.spec from rpm source makes the issue pretty clear:

# Csound is really dumb about 64-bit
Rebuilding csound on x86_64 with "%define useDouble 0" even for x86_64 resolved the problem with TamTam activities.

However, it is entirely possible that this workaround may cause some other applications which use csound to fail on x86_64.

Wednesday, August 13, 2014

OpenStack - Virtual Machine stuck in task state 'powering-on'

Today for the second time I had to search for the solution in http://dachary.org/?p=2939. Last time, I seemed to have selected the right keywords but it took much more effort today.

I just needed to reset task_state in instances table of the nova database:
mysql -e "update instances set task_state = NULL \
           where deleted = 0 and hostname = 'master'" nova
The problem may be caused by error in nova compute starting up as I use virtual machine manager as well.

Virtual machine manager creates images in /var/lib/libvirt/images which are readable by root only.

For some reason, nova-compute looks in this directory as well and gets errors like:
Stderr: "qemu-img: Could not open '/var/lib/libvirt/images/fedora20.qcow2': Permission denied\n"
I manually change the permissions to readable by all to overcome the problem.

Sunday, June 15, 2014

Running TamTam Activities on Fedora 20

While preparing an old machine to give to the children of our helper, I had to struggle a bit to get TamTam activities to run. I was using the Sugar environment on Fedora 20. The version of TamTam activities in the Fedora repository was old and did not work.

The solutions were as follows:
  • The tamtamorc.cfd file in tamtam/common/Resources/ needs an additional comma in line 62:

    $ diff tamtamorc.csd tamtamorc.csd.orig
    62c62
    < aindex, atrans, ifreq, iphase, itable, itabdur xin
    ---
    > aindex, atrans, ifreq, iphase itable, itabdur xin
  • On the x86_64 systems, in common/Util/Clooper, I needed to run make to make sure that aclient.so is built for the installed version of csound.

Wednesday, February 5, 2014

Getting started with Erlang Webmachine on Fedora 20

The problems I am encountering in learning erlang on Fedora 20 is helping me understand erlang better :)

I had to install erlang-ibrowse and erlang-meck even for starting the skeleton application. They should probably be included in the dependencies of erlang-webmachine rpm.

The template for creating the skeleton application is included in
/usr/lib64/erlang/lib/webmachine-1.10.1/priv/templates.

To create a new skeleton app:
$ cd /usr/lib64/erlang/lib/webmachine-1.10.1/priv
$ rebar create template=wmskel prefix= appid=

$ cd
$ rebar compile

The wmskel.template needed to be modified to comment out the following lines related to rebar:
%{file, "{{webmachine}}/rebar", "{{prefix}}/rebar"}.
%{chmod, 8#744, "{{prefix}}/rebar"}.

The version number in rebar.config also needed to be changed from 1.9.* to 1.10.*

However, execution of start.sh fails with the error:
 init terminating in do_boot ()

The issue was that in .erl, the following statement fails:
   ensure_started(mochiweb),

It appears that some of the dependencies of mochiweb are not implicitly started. I am not sure if I am missing something, this is a fedora specific issue or a current mochiweb version issue. A work around was to modify the start function in src/.erl adding the lines in bold:

start() ->
    ensure_started(inets),
    ensure_started(crypto),
    ensure_started(asn1),
    ensure_started(public_key),
    ensure_started(ssl),
    ensure_started(xmerl),
    ensure_started(compiler),
    ensure_started(syntax_tools),

    ensure_started(mochiweb),
    application:set_env(webmachine, webmachine_logger_module,
                        webmachine_logger),
    ensure_started(webmachine),
    application:start(webmachine_demo).

For diagnosing, modifying ensure_started function in the same file helped.

ensure_started(App) ->
    case application:start(App) of
        ok ->
            ok;
        {error, {already_started, App}} ->
            ok;
        X -> io:format("App failed ~w ~w~n",[App, X])
    end.


Now,
$ rebar compile
$ ./start.sh



http://localhost:8000  should show "Hello, new world".

It may be preferable to modify the start function in templates/src/wmskel.erl.

Thursday, January 16, 2014

Getting started with Erlang Mochiweb on Fedora 20

It is simple to use this tutorial for creating a minimal Erlang Mochiweb application. Clone the git repository and run make twice.

However, trying to do the same on Fedora 20 using the packages erlang-mochiweb and erlang-rebar wasn't so simple.

While the templates are included in the /usr/lib64/erlang/lib/mochiweb-2.4.2/support directory, it is missing the Makefile. We need to execute the rebar commands instead.

Several lines need to be commented in support/templates/mochiwebapp.template. These correspond to files not included in the erlang-mochiweb rpm package -
%%{file, "../../.gitignore", "{{dest}}/.gitignore"}.
%%{file, "../../Makefile", "{{dest}}/Makefile"}.
%%{file, "../../rebar", "{{dest}}/rebar"}.
%%{chmod, 8#755, "{{dest}}/rebar"}.
The script start-dev.sh fails. Solution is to replace '\\' by '\'. The script becomes:
exec erl -pa ebin edit deps/*/ebin -boot start_sasl \
    -sname {{appid}}_dev \
    -s {{appid}} \
    -s reloader
Now,
$ cd /usr/lib64/erlang/lib/mochiweb- 2.4.2/
$ rebar create template=mochiwebapp dest= appid=
$ cd
$ rebar compile
$ ./start-dev.sh

If successful, browsing localhost:8080 shows the success page.

Thursday, June 20, 2013

Inactive logical volume after upgrading to Fedora 19

I upgraded my netbook to Fedora 19 beta version using yum. The process was smooth and went through without a hitch.

The problem came up on rebooting. Systemd waited and finally failed to mount home, which was a logical volume. This seemed strange as root and swap were also on the same volume group and were being used.

Finally, lvscan showed that the home logical volume was inactive. The command
lvchange --activate y 
worked and it was a relief to realize that the home logical partition was perfectly fine.

Unfortunately, rebooting the system showed the same problem. The cause of the problem was that all the lvm2 services were disabled.

Enabling lvm2-monitor.service resolved the issue :)

Friday, April 12, 2013

NFS root unexpectedly squashed

While experimenting with setting up ltsp on Fedora 18, I came across a strange NFS behaviour which took quite some time to iron out.

I was already exporting /opt as a read only file system; however, with root squashed. LTSP added another export for /opt/ltsp with no_root_squash option. 
/opt *(ro,sync,no_subtree_check)
# export for LTSP version 5
/opt/ltsp   *(ro,no_root_squash,async,no_subtree_check)

Everything seemed to be sort of working with a few strange effects, e.g. I could not use passwords and some ltsp scripts were failing.
The problem was that root seemed to be still squashed:
[anil@localhost ~]$ sudo mount amd:/opt/ltsp/x86_64 /mnt
[anil@localhost ~]$ cd /mnt/home
[anil@localhost home]$ ls -l
total 8
drwxrwx--- 2 anil  anil  4096 Apr  6 13:04 anil
drwx------ 2 guest guest 4096 Apr 10 12:35 guest
[anil@localhost home]$ sudo su
[root@localhost home]# cd anil
bash: cd: anil: Permission denied
A workaround was to use fsid=0 although whatever documentation I came across seemed to suggest that it was no longer needed:
/opt/ltsp   *(ro,fsid=0,no_root_squash,sync,no_subtree_check)
Unfortunately, I had forgotten that /opt was also being exported and noticed it only after finding the work-around and getting ltsp to work on Fedora 18.

Sunday, March 31, 2013

Arch Linux installation using ipxe and a Fedora server

Arch Linux is great way to learn, e.g. installing Arch Linux booting over the network. As is usual with Arch Linux, the documentation for the process is excellent. Surprisingly, a mirror in India gave an excellent speed and low latency so even the first stage went well.

Since I was experimenting with ipxe, I decided to install Arch Linux using the iso and ipxe. Using dnsmasq was no problem. However, since I use Fedora and the default is dhcpd, I wanted to make it work with dhcpd. The problem  was finding the equivalent options of dhcp-option-force.

The issue was that the client would try to search for cfg file as per its rules and ignore the specification in the dhcpd configuration file. The solution was available on the syslinux wiki in response to
Can I send information to PXELINUX via special options in the DHCP response?
It is much harder syntax than the dnsmasq's dhcp-option-force but worked.


Saturday, March 30, 2013

Install an OS from a DVD iso without booting

While experimenting with LTSP on Fedora18, I realized that I would have to have a supported environment in order to be able to understand the failure on Fedora. I had an iso file of Scientific Linux 6.3 and decided to use that.

Since ltsp-build-client installs an OS in a chroot environment while the system is operational, I decided to see if I could use a LTSP script to install the Scientific Linux on a free partition.

A python program, chroot-creator, seemed a likely prospect.
  1. Commented a few lines in chroot-creator meant specifically for LTSP clients. 
  2. Chose a suitable kickstart file 
  3. Loop mounted the iso image and used it as the yum repository
  4. Started installation on on the free partition which failed.
Installation was not possible as the partition needed to be mounted and the chroot-creator installs the OS in a directory which should not be existing. So, the installation was successfully done in a directory 'Install' under the mount point.

After the installation:
  1. In Install:
    # mv * ..
  2. Modify fstab file for Scientific Linux
  3. Run grub2-mkconfig. It should find and include the Scientific Linux partition.
  4. Chroot to the SL partition
  5. Change password for root. Create additional users if needed.
Scientific Linux should now be a usable boot option.

This process should work with any distribution which is compatible with yum on Fedora.

Note: the experimental version of LTSP scripts now uses mock and chroot-creator program is not included.

LTSP On Fedora 18 using client created on Ubuntu 12.10

Exploration of LTSP turned out to be a very interesting challenge. My motivation was to write a monthly column for Linux For You.

My primary system runs Fedora 18. I thought that I would be able to get the scripts to run on Fedora 18 in spite of the explicit caution that Fedora 15 onward is not supported. I haven't succeeded so far but I did succeed in getting an client image created on Ubuntu 12.10 to run on Fedora 18.

I installed the server scripts from the repository for experimental version of LTSP 5 for Fedora 18. This ensured that that the ldminfod version was compatible with the ldm version on Ubuntu 12.10 client.

Ubuntu uses nbd by default. Unionfs root was not working with NFS root on Ubuntu as well. So, nbd version 3.1.1 needed to be installed on Fedora. The version in Fedora repository is 2.9.20.

LTSP scripts run nbd server using xinetd while Ubuntu 12.10 runs nbd-server as a system service. Since the xinetd option did not work, nbd-server was started using a system service script. The key extract from nbd-server script is:

DAEMON="/usr/bin/nbd-server"
test -x $DAEMON || exit 0
case "$1" in
    start)
    daemon $DAEMON 10809 -C /etc/nbd-server/config
The port has to be 10809 to be compatible with the -N option used by ndb-client on Ubuntu client.

/opt/ltsp/amd64, /etc/nbd-server and  /var/lib/tftpboot/ltsp/amd64 directories was copied from Ubuntu to Fedora. The following were the final steps:

  1. Run ltsp-update-sshkeys
  2. Run ltsp-update-kernels
  3. Run ltsp-update-image amd64 -f
  4. Change the dhcpd configuration files to use the amd64 directory in tftpboot instead of i386. I modified the /etc/dhcp/dhcpd.conf file and did not use the ltsp-dhcpd script.
If all has gone well, you will get a LDM login screen with Ubuntu theme. The sessions available will be the ones on Fedora 18 and you should be able to login to a session using your Fedora 18 credentials!


Friday, January 18, 2013

Upgrading to Fedora 18 using Yum - Nouveau causes system freeze?

The documentation for upgrading fedora using yum seems to be much better than before. A very nice script which automates the instructions was terrific. The upgrades of my desktop and the netbook were very smooth. After the upgrade, I installed the Cinnamon desktop as well. It is very nice though I will stick to KDE as I am now comfortable with it.

There was, however, a surprise on the desktop. On booting into Fedora 18, the display vanished and the system hung. The system came up in muti-user mode but not in graphical interface. Gdm was the problem. I switched to kdm. The login screen came and was fine in KDE. However, the system again froze when I tried Cinnamon or Gnome desktops. LXDE worked but the system froze as soon as I started Firefox!

KDE desktop was working with desktop effects disabled. If I enabled them, the desktop froze.

The desktop worked fine with the nomodeset option for booting the kernel. However, it was using the vesa driver. So, the problem is with nouveau driver on "GeForce 6150SE nForce 430" hardware.

Another curious result. The system is working fine with the kernel 3.6.11-1.fc17.x86_64 from fedora 17, which has made it possible to continue with Fedora 18 on the desktop.

Need to reconfirm the problems I faced on the desktop as I did not find a bug report with similar issues.

On Lenovo S10-3, I have so far not faced any issues related to the upgrade.

Friday, June 22, 2012

OpenLdap, Fedora 17 and Modifying Schema

Continuing my experiments with OpenLDAP, I needed to add mail attribute, which requires inetorgperson.schema. As I had not included it in the beginning, I wanted to modify  the schema. It should not be hard but I couldn't find a simple answer.

The discussion  "how-to-add-a-new-schema-to-openldap-2-4-11" gave a hint. Ldif files were needed and Fedora distribution includes them. So, I tried the the command
$ sudo ldapadd  -Y EXTERNAL -H ldapi:///  -f /etc/openldap/schema/inetorgperson.ldif

And it worked. However, since migration tools use the objectClass account which is inconsistent with inetOrgPerson, it turned out to be easier to recreate the ldap database.

Wednesday, June 6, 2012

OpenLDAP, Slapd, Fedora 17 and Authentication

Once the LDAP database is ready following the steps in the previous post, we can use authconfig-gtk to configure authentication via ldap. On Fedora, for using LDAP passwords either TLS/SSL or LDAPS is required.

The changes in Fedora 17 make getting started much easier. OpenLDAP creates a directory /etc/openldap/certs and creates an empty database of certificates (using /usr/libexec/openldap/create-certdb.sh)

During the installation, openldap-servers  runs /usr/libexec/openldap/generate-server-cert.sh which creates a dummy certificate for the local host and adds it to the certificates database in /etc/openldap/certs.

There is a small inconsistency, which should be resolved soon or it could have been caused by a file from earlier versions which is not replaced by the upgrade.

The files /etc/openldap/ldap.conf and /etc/sssd/sssd.conf use /etc/openldap/cacerts as the directory for the certificates. I needed to manually change that to /etc/openldap/certs.

When I was having problems with certificates, including ldaps in SLAPD_URLS in /etc/sysconfig/slapd and using the following command was helpful:
ldapsearch -ZZ -d 1 -x -LLL  -W -D cn=Manager,dc=example,dc=com -H ldaps:///
Update and caution: I find that slapd fails to start on reboot. It seems to timeout on some operation. However, it works fine upon:
$ sudo systemctl start slapd.service
Update: this was an issue of too small a timeout for my system in /usr/lib/systemd/system/slapd.service. Commenting the timeout solved the issue.
#TimeoutSec=3

Next: Modifying the schema.

OpenLDAP on Fedora 17 - Understanding Installation

As per the motivation in my previous post, I cleaned up slapd.d and various other files to start with a blank state on Fedora 17. Slapd would not start. It now needs slapd.d to exist.

Examining the installation script:
rpm -q --scripts openldap-servers
we notice that it creates fresh slapd.d at start as follows:
 /usr/libexec/openldap/convert-config.sh
                           -f /usr/share/openldap-servers/slapd.ldif
Obviously, the script is smart enough to upgrade the existing files and database in case slapd is already running.

We can customize slapd.conf as follows for our needs:
  1. Modify realm in olcAccess, olcSuffix and olcRootDN entries. 
  2. Add an entry for olcRootPW -  olcRootPW:"slappasswd output"
  3. Add needed schemas, e.g. cosine and nis as only core schema is included by default.
Create the starting slapd database and start the daemon:
$ sudo /usr/libexec/openldap/convert-config.sh -f slapd.ldif
$ sudo systemctl start slapd.service
 I created base.ldif, users.ldif and groups.ldif using the migrationtools and added them to the ldap database:
$ ldapadd -x -W  -D cn=Manager,dc=example,dc=com  -f base.ldif 
It should now be possible to use this server for authentication.

More in next post.

OpenLdap, Slapd and Fedora 17

Single most useful statement about OpenLdap I found was in "LDAP for Rocket Scientists" :
The bad news is that IOHO never has so much been written so incomprehensibly about a single topic with the possible exceptions of BIND and ... and ...
Last time I had used slapd was some years ago. I needed to help a colleague. Fortunately, it was on Ubuntu and the absence of slapd.conf was not too intimidating. It wasn't hard to find that all one needed to do was
# dpkg-reconfigure slapd
I would need to help my colleague some more. So, I decided to set one up at home - on Fedora 16. And that is when I found the comment from "LDAP for Rocket Scientists". There did not seem to be an equivalent of Debian option for getting started. Also, the slapd.d files are substantial differences in the files in slapd.d in Debian and Fedora. Although I managed to get started using ldapmodify, the feeling has been that there has to be a simpler way, especially when I started using tls.

I used self-signed certificates but was having difficulty in getting the certificated trusted. Meanwhile, I upgraded to Fedora 17. There were changes in the way slapd is setup. Instead of /usr/openldap/cacerts, it uses /usr/openldap/certs directory. There are some scripts like generate-server-cert.sh and upgrade-db.sh. There must be some documentation somewhere about these changes. I just haven't found it yet.

So, I plan to drop the slap setup done so far. Start afresh on Fedora 17, making use of the tools provided and see if it makes life simpler.

A few simple things which have tripped me so far -
  • Each ldap application is a client and has its own configuration file. It does not need to use /etc/openldap/ldap.conf
  • Fedora now relies on sssd for ldap authentication. Since I keep upgrading my system, it did not have this server and was using nss_ldap and pam_ldap.
  • The 'Common Name' on the certificate. 
The steps in next post.

Saturday, June 2, 2012

Upgrading to Fedora 17 - using yum

Since my experience with preupgrade on the desktop was not so great, I decided to take a chance with upgrading my Lenovo S10-3 netbook to fedora 17 using yum.

The additional steps of modifying the filesystem using dracut were not really complex.

Most of the packages had already been downloaded by preupdate, which I had preserved. I copied them into the cache of  yum and executed:

# yum --releasever=17 --disableplugin=presto distro-sync

Unfortunately, after updating about 500 packages, yum seemed to be doing nothing. I killed the command. And ran yum-complete-transaction. It seemed to be using the repositories of Fedora 16 even though fedora-release files had been installed. So, I ran

# yum-complete-transaction --releasever=17

After a pretty long time, it told me that there were problems. I tried again with

# yum-complete-transaction --releasever=17 --skip-broken

An equally long wait and no better result. The problem was that rpm database had entries for both 16 and 17 versions for the packages which were updated.

The following command also did not help (Next time, I need to try with  the -t option to see if it would have tolerated errors).

# package-cleanup --cleandupes

The problem was that packages which had not yet been updated depended on the duplicates. Had I allowed this script to run, it would have deleted most of the packages.

I found a python script I had written when an upgrade from FC7 had failed because of power failure. The script created a file with the list of older duplicates, which could be used as an input to rpm as below:

# rpm --nodeps -e `cat deleteList.txt`

Finally, I cleaned up the failed yum transaction and ran:

# yum --releasever=17 --disableplugin=presto distro-sync

This time, the upgrade finished cleanly. Although it took about the same time and effort as the preupgrade, I enjoyed solving these problems a bit more.

Firefox crashes

As on the desktop, firefox crashed with even a few tabs. It seemed to be a random problem. However, I downloaded Firefox 12 from Mozilla and firefox works fine!


Updgrading to Fedora 17 - preupgrade

I took this advice in upgrading via yum seriously :
However Fedora 17 is very special. You should seriously consider stopping now and just using anaconda via. DVD or preupgrade, unlike all previous releases it's what the yum/rpm developers recommend. Continue at your own risk.
I decided to use preupgrade. I would have preferred yum as I would have more control over the update even if it were riskier. Anyway, the preupgrade went through nicely overnight. About 4 GB was downloaded and I was ready for the final stage.

Uses grub2 

I rebooted the system and it did nothing. I have continued to use grub and had not migrated to grub2. Preupgrade had created a new file grub.cfg in /boot/grub2. After failing to get the upgrade kernel to boot from grub, I installed grub2. It was easier than I had feared. It left the grub.cfg file untouched. I rebooted and the upgrade started.

It soon told me that I needed an additional GB of space. After making the additional space, I rebooted and the upgrade started. Everything was fine until it was cleaning up files. It just wouldn't end. I noticed at least 3 times glibc being cleaned up. There was little option but to reboot.

The reboot went through the upgrade process and felt that everything was done. I was ready to reboot into Fedora 17, except that the grub.cfg file was still the same and the preupgrade files had been removed. Fortunately, using the minimal editor in grub, I could boot using the F17 kernel. The first thing I did was to create a new grub.cfg file. The fireworks on the desktop looked nice.

SSH and password-less login

One minor issue was that I needed to give the password for using ssh from my remote system. I needed to copy authorized_keys2 to authorized_keys in .ssh.

Firefox crashes

Firefox seems to crash with a few tabs. It seems to be a random problem. However, if I download Firefox 12 from Mozilla, it works fine!

Save preupgrade files in case you want to upgrade more than one system.

I did not want to download the files again for my netbook. As a precaution, I had saved all the preupgrade files, in particular the rpm packages. As I feared, it cleaned up and even though keepcache was set, there were no packages of fedora 17 in the yum cache after the upgrade.

Monday, March 5, 2012

Overcoming Slow Boot of Fedora 16 after LiveCD installation

I had failed to upgrade Lenovo S10-3 netbook to Fedora 16 using yum as I have been doing for several years and successfully did on my desktop. The system became unusable under Fedora; so, I could not diagnose the cause.

I installed KDE livecd spin on the netbook. The boot time seemed to be ages in comparison to Fedora 15 and, especially, Arch Linux which I normally use on this netbook.

Searching the net for plausible reasons led to using "systemd-analyze blame". The top of the list was "udev-settle.service", which really is not the issue.

Anyway, I noticed that there were livesys.service and livesys-late.service which are not needed once the livecd is installed. The time shown for these by "systemd-analyze blame" was 290ms and 44msec respectively. Hardly something to worry about. However, disabling the livesys and livesys-late services resulted in the userspace boot time decreasing from 87 sec to 36 sec! The overall decrease was 97 sec to 44  sec :)

Now, "systemd-analyze blame" gave a little more useful details. The top entry was iscsi.service. Wikipedia entry indicated that this was not something I was likely to use. Disabling iscsi and iscsid services reduced the userspace boot time to 27 sec and overall time to 37 sec.

Removing mdmonitor-takeover and lvm2-monitor services did not make any significant difference.

Disabling httpd and and mysqld, which I normally do not need on the netbook, saved another 5 sec and the boot time now is 32 sec of which 22 is the userspace time.

Next step is to use bootchart to see if I can understand where the time goes before the system becomes usable.