What's new?
- Transparently to the user, the whole thing has been rewritten to use model-view-controller paradigm (original initiative by Duncan MV)
- Window size and its position on the screen is now persistent - this is something users have been asking for for ages, YaST CC window used to open always in the same hard-coded size, no matter the resolution. Due to QSettings magic, coding it was incredibly easy
- Remember you now have to double-click the icon to launch the YaST module (single click is reserved for something that is not fully implemented yet)
- Modules are searched (filtered) as you type in the search field - that means no more opening of extra window to search. Search is done over the names only, keyword search to come soon :)
Footnote: the bubblegum pink is not supposed stay in the real version. It is my little gift to Pepa Reidinger.
YaST partitioner can now (since feature #305691 is implemented) do ext4 and in addition to that (to really stress-test the feature and have possible bugs reported asap), ext4 has been made a default filesystem for openSUSE 11.2. And though I'm not in the position to really appreciate and make use of all the cool ext4 features, I'm sure there is bunch of our users that will.
Now don't thank me, thank captain Arvin as it was him who did the work and added ext4 support to the partitioner (in one afternoon, so to say). And while you're at it, you can send him some beer :) :D
- Mood:
crushed
So - what does keep_install_network parameter, set to 'true' and inserted into <networking> section of AutoYaST profile, do? One can intuitively guess that it will preserve network configuration - that is, interfaces setup, resolv.conf bits, static routing, udev rules & co. - from 1st stage of installation (of course, only if the installation actually runs over the network) and it is indeed like that. Uwe blogs about it in more details
But unless you use openSUSE Factory, please don't try this at home :)
<networking> <keep_install_network config:type="boolean">true</keep_install_network> </networking>Network interfaces setup (ifcfg files) from the installation will be successfully preserved, but due to a bug, your static routing configuration (if you have any) will be moved into backup file and YaST won't create a new one and you will lose most of the information in /etc/resolv.conf. Unfortunately, nobody got the idea to test with the profile containing nothing more but keep_install_network entry in networking section so far :(
The bug is fixed now for openSUSE 11.2 and SLE11 SP1 (if nothing in particular sub-section of networking section is defined, the setup from installation is used, but AutoYaST profile is the higher authority here). However, if you use SLE11, you'd better install with profile containing at least minimal DNS and routing info, for example like this (set search domain, 1 nameserver and default gateway):
<networking>
<keep_install_network config:type="boolean">true</keep_install_network>
<dns>
<dhcp_hostname config:type="boolean">false</dhcp_hostname>
<domain>home.net</domain>
<hostname>dolphin</hostname>
<nameservers config:type="list">
<nameserver>192.168.0.2</nameserver>
</nameservers>
<searchlist config:type="list">
<search>home.net</search>
</searchlist>
</dns>
<routing>
<ip_forward config:type="boolean">false</ip_forward>
<routes config:type="list">
<route>
<destination>default</destination>
<device>-</device>
<gateway>192.168.0.1</gateway>
<netmask>-</netmask>
</route>
</routes>
</routing>
</networking>Or use a workaround post-script Uwe posted to bugzilla, to backup your setup and to restore it later. One good thing about these bugs is that not only it broadens your knowledge (when user comes up with scenario you never thought of) ;-) but it also helps us to improve things. keep_install_network feature is now documented and not secret anymore. Enjoy it!
- Mood:
busy
And now repeat after me:
"I will never partition my disk without creating separate /boot partition"
A small intermezzo: though I've been pretending that I'm doing some YaST development for almost 3 years already ;-) I'm not really a technical person. I know a lot about widgets, user interface, usability and all that fancy stuff, but my knowledge of the system configuration ends in /etc/sysconfig or /etc/fstab at most. When it comes to something like system boot, I'm completely lost. At least I admit to it :-) :-D
The installation went on fine - I picked KDE4 as my default desktop environment, had the partitioner shrink Windows partition, created root and /home partition, double-checked whether I got the bootloader installation options right ("Boot from root partition" - check, "Boot from MBR" - uncheck, "Set active flag for boot partition" - check, "Write generic code to MBR" - uncheck) and watched the slideshow. The standard set of 1st stage finish scripts followed and then bang! - "Failed to install the bootloader. Try the configuration again?" (or something along those lines). Hm, if I answer "Yes" now, I'm smart enough to figure out it'll fail again, I thought, unless I change something - but what? Looking at y2log did not make me any less helpless - the last thing I saw was how bootloader uses some cryptic Perl script (/usr/lib/YaST2/bin/tp_mbr, to be exact) to detect ThinkVantage sequence in MBR and preserve it.
Nevermind, I rebooted, picked "Repair installed system" from the installation options and hoped that yast2-repair will help me find out what went wrong. Not surprisingly, it did not. It only showed me already well-known message about failed bootloader installation - quite a cruel joke :) At this point, I gave up. Trying to solve a problem where I don't understand a single bit of its principles is not that much like me. And after all, there are more pleasant ways how to spend Friday night - dancing salsa, for example ... :)
But don't get desperate, my friends - this story has a good ending. I brought my laptop to the wizard :-) I was not looking over his shoulder as he was working, so I don't know what magic spells and potions he used, but I know he did the following:
- Created partitioning setup with separate /boot partition and told the bootloader to boot from it (that was maybe the crucial point)
- Added a repository with openSUSE 11.1 updates as an add-on during installation
- Made extended partition (with swap, /, /home and /boot) 1 cylinder smaller, as ThinkVantage partition at the very end of the disk did not begin exactly at the cylinder boundary
In conclusion, I consider myself to be quite lucky that I'm surrounded by many wizards (bootloader wizard, installation wizard, KDE wizard, some wireless stuff wizards, suspend wizard, ... ) ;-) What do normal openSUSE users who can't grab their machine and bring it to a wizard do, if the same (or similar) thing happens to them? "Oh, they go to #suse and cry there. Or they simply give up and go using Ubuntu" says Darix (whom I sometimes chat with when I suffer from insomnia and he stays at work at night). Sad to say that, but it's probably true ... :-(
- Mood:
blank
Needless to say more :
"Not sure how you are doing it, but you always make me smile when we are talking."
"I know how - because you are doing the same. It is then easy to smile in return."
Wish you a nice day (evening/night, depending on the timezone you are in) and if you haven't got any compliment today so far, try to give some out :)
P.S. Exceptionally, I am being positive. Enjoy it, it does not happen to me very often :D
- Mood:
satisfied
This year, I also participated. With Miso Zugec, we had a joint talk on network-based installation and AutoYaST. Miso opened the talk by saying that for installing openSUSE on your machine neither you necessarily need any of the usual pre-requisities such as DVD, hard-disk or monitor, nor you have to spend 1 hour in cold server room clicking and answering installer's questions. He has shown some practical examples of how to use installation repository on network, install on iSCSI disk, or remotely via SSH or VNC.
I went on to introduce AutoYaST - a tool that comes in really handy when you install often, install lot of machines and you want to automate great part of the process. I introduced the basic concept of AutoYaST, showed folks the smallest AutoYaST profile in the world, how to clone your system and mentioned even some advanced AutoYaST usage, such as "<ask>" feature (a simple way of interactively asking for user input - such as root password or hostname - in the beginning of installation), or AutoYaST scripts.
In general, the talk was a success and I'm not saying that just because the presentation room (with ~100 seats) was so full that people had to stand on the corridor as they did not fit in. For me, much more significant measure was the number and meaningfullness of the questions people were asking in question time. At the end, I was really sorry that I did not have more time, so I could have introduced even more AY features, such as rules.
We spent the rest of the day in our openSUSE booth. To attract more visitors, a quiz question on openSUSE (Did you know when the openSUSE project was founded? Or how many binary packages is there in our BuildService?) was published every hour or so and folks could submit their answers. At announced time, three correct answers were drawn and winners got openSUSE T-shirts, plush geekos and other presents.
Other open-source project also participated on the event. For example, our booth was just next to Ubuntu's one (it was funny to see how people used Ubuntu machines in there to google for correct answers to openSUSE questions :) ). All in all, Pavol has some interesting pictures from the event (these are from Day 1) and there is also an article on LinuxExpo on root.cz (in Czech only, I'm sorry).
P.S. root.cz could definitely benefit from hiring a better photographer ... and I'm not saying that just because I, unlike the photo, don't look like zombie in real life :D In general, much of the photos from the talks are of rather bad quality, considering the fact that you can do much better with my beloved Canon EOS 350D (which is what their photographer also had).
- Mood:
lazy
As you probably noticed, for openSUSE 11.2 our goal is to significantly improve usability of YaST partitioner. I want to show you a feature that is in partitioner for quite some time already, yet it is quite little known. It helps you to customize the partitioner to best suit your needs.
One of the frequent complaints about partitioner was that it is "overengineered" and it presents so much information that it is really confusing for the (home) user i.e. the "1 laptop, 1 hard disk" usecase. While there are some other problematic areas, this particular one can be fixed rather quickly and in a simple way. And by "fixed" I of course do not mean that from now on, we will tailor the partitioner only to the needs of Aunt Tillie (Oma Krause), leaving the power users high and dry. Let's have a look at partitioner settings (that is, we'll switch to the branch labeled "Settings" in the left tree panel), especially at "visible fields" selection box:
Here you can set which information on storage devices you want to see, that is, how many columns the tables are going to have and how much details the overviews are going to contain. The less boxes you tick, the less details that only uselessly fill up the screen you'll see. For example, if you use neither LVM nor RAID setup, seeing "used-by" field is probably of no use to you. Similarly, if you have laptop with one hard disk, you don't need fiber channel ID bits of information. And since these settings are written to sysconfig, they are persistent. This is the default sysconfig configuration shipped with openSUSE 11.1 (and SLES11):
Too detailed and not much home-user friendly, now is it? This is the new, simplified default for openSUSE 11.2:
If you are a power user who uses advanced setup and wants to see more detailed information, you now know where to go and make it visible again :) Besides data presentation details, you can also pick a default filesystem or default mount-by method for newly created devices here.
Everybody else is doing it, so why can't we?
If you have ever used partitioning GUI tools in other distribution, even on other operating systems (GParted, PartitionMagic, DiskDruid,...), you have noticed that almost every one of those has some graphical representation of how the disk is partitioned. From now on, even YaST partitioner does:
However, compared to other partitioners, our bar graph is rather dumb. It is not interactive (if you click on a partition in graph, nothing happens) and it does not even highlight current partition as one scrolls down the table. At least a tiny little improvement is that it can do tooltips now, so if the partition description text is too wide it does not fit the graph segment, the text is still replicated in a tooltip.
Do you like the graph? Do you want to have it improved? If so, please vote for feature 303534 in openFATE. I'd really like to have at least highlighting the current partition implemented (preferably, by thick pink border :) :D
- Mood:
sick
As Murphy's law states, if things can go wrong, they certainly will and usually at the most inopportune moment. Not surprisingly, as SLE11 slowly approached to becoming gold, the weirdest bugs, corner cases and users making up the most exotic test scenarios started to pop up from just about everywhere. The pieces of code I maintain were not an exception. Alors, this time, I'm not going to write about some exciting new stuff I'm hacking in YaST (well, of course I'm currently working on something, but I'm going to make it public when the time comes - in the moment I'll be quite certain that it is not absolute fiasco :)). The final phase of product release is an ideal time for sharing quantum theory of bugs. Take this post as an example of junk literature ;-)
I'm sure every sw engineer knows the situation. A bug 100% reproducible at customer's site, with sufficiently high priority and bunch of important managers in Cc: that mysteriously disappears as soon as you try to reproduce it. It smells the debugger from afar and flees quickly enough ;-) That is so-called Heisenbug. Quoting Wikipedia:
A heisenbug (named after the Heisenberg Uncertainty Principle is a computer bug that disappears or alters its characteristics when an attempt is made to study it. The name heisenbug is a pun on the Heisenberg uncertainty principle quantum physics concept which is commonly (yet inaccurately) used to refer to the fact that in the Copenhagen Interpretation model of quantum mechanical behavior, observers affect what they are observing, by the mere act of observing it alone"
Or look at Schroedingbug - another one of those mysteries. Let's see what Wikipedia says again:
A schroedinbug is a bug that manifests only after someone reading source code or using the program in an unusual way notices that it never should have worked in the first place, at which point the program promptly stops working for everybody until fixed.
SLE11 debugging phase was sufficiently long to come across one of those, too. I was reading the source code (of YaST ncurses packager this time), cursing myself how could I possibly overlook such an obvious usage of NULL pointers, wondering how comes it has never crashed for anybody and suddenly bang! There is was - a critical bug from our Three-Letter-Customer, complaining that "yast -i crashes" . Guess where :-)
If you love quantum physic humour or if you just need some entertainment in the quantum of bugs you're dealing with, point your browsers here and read about bohrbugs, mandelbugs, phase of the moon bugs and other nightmares.
And while the customers are testing bugfixes and another set of packages is being built, I can moan and groan on IRC query with Uwe. It was actually him, who pointed me non-quantum layer 8 bug notion (if you don't get it, review your OSI layer knowledge first ;-)). He told me: "Go ahead and tell these Three-Letter-Customer guys that what they are experiencing is a layer 8 bug. It will make them feel special." So I did. They didn't seem to share the same sense of humour :-) :-D Anyway, we agreed that quantum debugging should be discovered ASAP.
- Mood: blank
It was the same with YaST package manager and pop-up question from the title of this post. I'm sure we all remember that one:
It was introduced in openSUSE 10.1 (aka BrokenSwManagement edition) in order to alleviate suffering of the poor users forced to use our package management (powered by zmd and baby-libzypp) with ultra-slow start-up. libzypp grew faster and faster over the time, but the pop-up question remained and (quite reasonably) it started to annoy users. "Why do I have to click to have this crappy pop-up disappear?" they asked. "I've made my choice, installed all packages I wanted, so I want to answer no further questions."
After many heated discussions, we finally made the pop-up go away in openSUSE 11.1 After clicking on 'Accept' and installing all packages, package manager simply ended. That, of course, made the other half of the users speak up: "Why YaST does not ask anymore whether I want to install more packages? I don't want to start package manager anew each time. I simply want to have an option to install something more I forgot about in the first round."
In openSUSE 11.2, my colleague lslezak (now the link to his blog should be here, but he is too shy to have one :)) used really ingenious way of cutting the Gordian knot - he made the behaviour on exit from package manager configurable. And not only that - besides an option to close package manager (for those who want to be done with it) and option to restart it (for those who may want to come back and select something more), he added a third one. When the package installation is over, you can choose to display a neat summary of what has been installed/deleted, how long did it take and view some detailed logs. Then, you can either finish, or go back to install more packages:
Now all you have to do is to open /etc/sysconfig/yast2 file in your favourite editor and set PKGMGR_ACTION_AT_EXIT variable to some reasonable value. Please find more detailed information here.
"But I don't want to edit some cryptic file manually," you might think. "Isn't there any other way?" Well, of course there is. YaST ncurses package manager has a brand new menu that allows you to pick the exit action of your choice in a few key presses:
There are some minor things left to polish, but it basically works by now. Better don't ask me how the sysconfig variable is actually written :-) It took me by surprise to realize that libzypp's interface to sysconfig is read-only, so I'm impatienly waiting for Augeas ;-)
- Mood:
sleepy
An e-mail that would make my day and have me smile all over my face several days after that does not land in my inbox very often. It is not so long ago when I received one such. It was just an ordinary reply to my e-mail, yet it contained something very special and very precious in these days - a compliment.
It was not one of those nerdy attempts to be witty and yet to tell something positive, such as "You look really superb today - like a T-Systems cascading style-sheet" (I was wearing grey in combination with white and pink) or "What a beautiful dress, mademoiselle. It goes so well with the chairs in our dance club" (the chairs in the club were of different shades of scarlet, the DJ was a half-inteligent moron). Quite the opposite - simple, genuine and to the point, without the trace of false flattering - just the things I expect from a compliment. I still have to smile when I remember it. Thanks a lot, Lars.
As I already said, compliments are rather precious goods and this particular one made me think about certain aspect of human communication protocol I did not think about before. Any handbook of etiquette ("how to behave" rules in this context, not the piece of paper on the bottle of wine ;-) ) usually says something along these lines: "Gentleman never forgets to compliment a lady about a new dress. He notices her new haircut or a new hat", advising ladies to smile and to thank for the compliment (I'm just wondering how comes that other possible responses to that - for example saying "Don't you notice how fat I look in it?" or calling the poor guy horny bastard - became much more common in these days).
Any handbook of etiquette however leaves ladies high and dry when it comes to complimenting a gentleman. Is it wise to mention the way he looks ("Yes, sir, you look really gorgeous in black suit, but do you actually notice how weird it sounds if a woman tells you so?"), or is it better to pinpoint something he did/does well? Lately I tried to compliment a colleague, because I was really impressed by the smart script he wrote in order to make searching for NFS servers on local network much faster ... and without much success, or so it seems. Either he did not understand what I was saying (and why I was saying it), or was too shy to reply, or maybe it was no acceptable means of appreciation for him. Oh well ... did not leave me any less confused.
Alas, accepting compliments seems to be much easier than giving them. All in all, ladies (and especially) gentlemen - please help. How to compliment, not to insult and not to receive blank stare as a feedback?
- Mood:
thoughtful
Well, yes, the webpin client is hidden - 'yast -l' does not show it and there is neither an icon in control centre, nor a menu or a button in other YaST module one could simply click and search the packages using webpin service from within YaST. You simply have to know the command (yast2 webpin_package_search) and type it in the shell. One of the reasons we did not make it more visible in openSUSE 11.1 was that the tool was not in the state we could be exactly proud of :) (due to lack of time to polish it in SLE11 bug typhoon :) ) There were two major flaws of yast2-webpin:
- It did not remember selected packages in multiple queries - the user could do many searches and select several packages in each of them, but only packages selected in the last query were forwarded to OneClickInstall wizard at the end
- "All Selected Packages" tab (intended to be used for viewing all packages selected so far) did not do anything bad, but did not work either. It always showed a blank list.
Making it all work
Good news: none of the above will be true anymore with pending yast2-packager check-in into Factory. How does it all work then? Suppose I want install some additional games into my openSUSE system. I'm a devout chess player and playing with computer is fun (especially when there are no human players around), so let's search for "chess" expression and pick something then - brutalchess will do. Fish Fillets is another of my favourite games and after hitting Search button for the second time, I'm voting for fillets-ng and fillets-ng-data packages:
Now let's check if webpin client really remembers user's selection from both queries and switch to "All Selected Packages" tab. Yes, all three are there and they're succesfully forwarded to OneClickInstall Wizard later (after clicking on Next):
Where to place it?
Bad news: I still did not find, what I was looking for - a decent shelter for webpin_package_search client :-( Now it all works so well ;-) it would be really nice to let all users (not only those who waste^Wspend their evenings reading PlanetSUSE blogs :-)) know the functionality is there and they can use it. There are three options I can (and certainly many more I can't) think of so far. But the thing is, I don't particularly like any of them as they all have certain drawbacks. Here they are:- Place a new icon into YaST Control Centre, Software section. Drawback: there is already too many icons in Software section, which is certainly very confusing for the users, so we're trying to reduce number of them as much as possible. Adding a new webpin icon would contradict this effort.
- Make search using webpin accesible from package manager's menu (I'm using ncurses PM as an example here as Qt packager is being rewritten atm). Drawback: it is just a little bit less hidden than now - you have to know the menu item is there so you can use it:
- Add a new button to package manager's search screen. Drawback: in my H.O., it looks ugly :)
Feedback wanted
To solve this problem, I need your feedback and your ideas. What is, in your opinion, the best place for YaST webpin client? Do you like any of ideas I presented? Or do you have your own idea from where would you like to access webpin client? If yes, don't hesitate to drop me a comment.- Mood:
accomplished
It was only the next day as I was having my lunch (I know it sounds surreal, but it was really so) when it finally dawned on me. We have "Rescan Disks" button, hidden in "Hard Disks" configuration screen and it does exactly what Jozef wanted to do: re-reads partitioning configuration.
Not that I would want to encourage you to use different tools than our partitioner *, but sometimes you really want/need to do it. Perhaps you don't feel comfortable with clickety interface, you are much more familiar with CLI tools and you want to use GUI just for some minor adjustments (e.g. defining mount points) ... Whatever, if you want the partitioner to pick up your hand-made configuration, press "Rescan Disks" button.
( *) it is not a supported scenario and if you do so anyway and run into problems, you should not ask us for help in Bugzilla :) in other words, do what I suggest here only if you know exactly what you are doing )
Come to think of it, hard disks and partitions are not the only two types of storage devices. You might want to use CLI utilities to create e.g. LVMs or RAIDs (even during installation, necessary tools are in inst-sys because partitioner calls them for you if you use clickety approach) Wouldn't the "Rescan" button be better off on the main partitioner screen? Like this:
Bright future ++
In openSUSE 11.2, we will be (among other things) working on improving the usability of partitioner interface. That includes resolving currently opened usability-related bugs, but for example also reducing the time user spends in the interface searching for the right dialogs and right buttons performing the most common tasks (which is, in my opinion, one of the most prominent usability flaws of the partitioner).As for the new feature set, partitioner plans for 11.2 are still mostly up in the air, but you can already try an hors-d'oeuvre from our YaCHT kitchen, brought to you by the main cook captain Arvin. Coded with love and passion, try it :D A nice tool to visualize the structure of storage devices on your system, to show where the volumes are mounted and how are they bundled into LVMs/RAIDs. The whole thing will look even cooler in the future and the graph nodes will be clickable.
Oh, and before I forget: there are two "easter eggs" in the screenshot in Arvin's blogpost. Let's see if you can find them :) I found one and, looking for some well-known mathematical constant, such as π or e, I did not see the forest for the trees :D
- Mood:
exanimate
In most of the cases, installation went on smoothly and users really appreciated a panel with the list of installation steps that was visible at all times, showing them where exactly in the installation workflow they were. But sometimes, it was necessary to make a side-step from the main workflow and open a new dialog, which covered the steps. That was something Good Project Manager Stano did not like. He said: "Installation looks ugly without steps" and asked YaSTees do to something with it. So they did and since then, no dialog ever made the steps invisible again.
But things weren't always so idyllic in openSUSE community. An evil and very, very old creature - Ancient Screen Resolution from the Last Century, nicknamed 800x600, lived in Novell-land and sometimes it was sent by mischievous X11 gods to squat in the magic boxes of ordinary openSUSE users. As installation steps occupied almost one third of user's screen, little of space was left for the rest of installation clickety stuff in such case. Users were unhappy, as partitioning the disk or configuring the printer was now rather cumbersome for them. Here is what they've seen:
Two of YaSTees' wizard friends, old QFrame and his son, QSplitter gathered and were thinking about how to help YaSTees to make their users (especially those who were hit by 800x600 beast) happy again. Old QFrame wizard knew how to group all his children widgets horizontally side by side and passed all his knowledge to his son, but QSplitter went even further. He learned how to insert small knobs between his children, and with the help of user's mouse, he could change the proportions of the window occupied by each individual widget, eventually make some of the widgets completely disappear and appear again. QFrame said: "I am very old now and I grew tired in YaSTees' services over the time. And this task is already too much for me and my abilities. It will be better, if you take over, my son, and from now on, it will be you who is responsible for arranging all those misbehaving widgets in the installation". And he retired, packed his luggage and went travelling around the world.
It was a great challenge for QSplitter wizard. The task was easy with the dialogs of the main installation workflow, but taming the dialogs of sub-workflows was much more difficult quest. As unlikely as it may seem, what can be seen here is not one "window", but two of them, overlapping each other in such a way, that only the side panel with steps is visible from the bottom one:
But QSplitter finally succeeded. What did it mean for openSUSE users? Now even if 800x600 evil creature resided in their magic box, thanks to QSplitter they could use their mouse, hide installation steps for the time being and give more space to the tool for partitioning their disk (configuring their printer). Then, they could of course recover the steps again. Here is how it looked like:
At the end, everyone was happy. And that, dear children, is the end of this fairytale. We have proven that the solution exists and we can go back to sleep :-) :-D
Acknowledgements: to HuHa for his YDialogSpy (excellent debugging tool), to Good Project Manager Stano for his spiritual support :) and to captain Arvin for the final impulse, so I stopped lazying around and finally got down to doing something
- Mood:
indifferent
First some bad news for 11.1 openSUSErs (SLES/D ones, on the other hand, can celebrate):
Changing hostname with YaST
It has always been fascinating for me to observe computer naming schemes people choose. Middle-Earth geography, hard-to-pronounce spider genus names (a colleague of mine is a devout spider breeder), coolo's female characters from Shakespeare plays ...
When it comes to setting the hostname of your machine so that it fits your naming scheme :-) there were two important milestones in YaST development:
- Since 11.0 you can opt for installation with automatic configuration. In other words, the installer asks minimum of questions and proposes some reasonable default values otherwise, so you don't have to click 'Next-Next-Accept' so much.
- YaST and NetworkManager marriage tied together via sysconfig bound has been officially divorced in 11.1. NetworkManager now uses its own settings system independent of system-wide /etc/sysconfig. Therefore, if NetworkManager is in charge of controlling the network and you run YaST network configuration module, most of the fields for inputting some values will be greyed-out.
Fortunately, allowing to change hostname in YaST is a question of un-disabling two widgets (compared to more work with adding related UI to NM connection editor). Don't be scarred off by this pop-up message:
Just switch to Hostname/DNS tab and set the hostname of your choice:
But unfortunately, only in SLES/D 11 and in openSUSE 11.2. It was too late for 11.1 :-(
Punycode? What the ...
If the world was ideal (in this particular case - composed of ASCII-characters only ;-)), it would be certainly quite boring. As non-ASCII characters in hostname and domain name would drive hostname resolvers crazy, smart people came up with punycode, which is a schema for converting such hostnames into RFC-compliant character set. Thus, a domain names příliš.žluťoučký.kůň.cz * or 我爱你.zh ** become, after converting to punycode xn--pli-rma35ctb.xn--luouk-uva4it5a4g.xn-
Many thanks to Lukas for this Punycode YCP module (originally written for yast2-dns-server, because we support punycode in DNS zones, too), without it, it would be much more difficult to add punycode support to hostnames configuration. And again, this candy is only for SLES/D users :-( (or those patient enough to wait for 11.2)
i18n in yast2-apparmor - saga continues
Ok, so I thought I was particularly smart when I thought I made yast2-apparmor finally see the right translated strings, as I describe it here. Well, not surprisingly, I wasn't. Two programs - AppArmor UI frontend (YaST) and AppArmor CLI backend (genprof & friends) - talk to each other, but use different textdomains (originally, they didn't, I changed it in order to have yast2-apparmor pot files generated together with those of other YaST modules).The key to make strings from both sources correctly translated is not to overwrite textdomain to 'yast2-apparmor' on global level, but to use customized gettext function for YaST UI strings and 'apparmor-utils' otherwise (globally). In case you'll ever need it, here is 'mygettext', doing the job:
setlocale(LC_MESSAGES, "");
my $dom = Locale::gettext->domain_raw("yast2-apparmor");
$dom->dir("/usr/share/YaST2/locale");
$dom->codeset("UTF-8");
#bubli's own variation of gettext, because we need to
#translate strings in two textdomains
sub mygettext
{
my $msgid = shift;
return $dom->get("$msgid");
}
Oh, and if you happen to see the strings coming out in incorrect encoding, please vote for this bug.*) it means 'a horse too yellow' - not very meaningful phrase even in czech, but it is used to demonstrate as many accented czech letters in as few words as possible
**) decrypting this is a homework for watchful reader :-)
***) if you use some interesting host naming schemes, you can drop me a comment :)
- Mood:
pessimistic
Shop assistant: I'm not sure we have it, sir. Have you checked our economics and finance section?
This happened to my brother as he walked into bookshop in hunt for Christmas presents. It's always good to know what one has on stock :-)
- Mood:
stressed
#! /usr/bin/perl -w
use YaST::YCP;
use YaPI;
textdomain("cool-module");
#here comes YaST awesome underscore macro
my $string = __("My grandmother has a green parrot.");
How to achieve the same thing in bare Perl script (e.g. an agent) used by YaST?
#!/usr/bin/perl -w
use Encode;
use Locale::gettext;
use POSIX;
setlocale(LC_MESSAGES, "");
my $dom = Locale::gettext->domain("cool-module");
$dom->dir("/usr/share/YaST2/locale");
textdomain("cool-module");
my $string = decode( "utf8", gettext("My grandmother has a green parrot.");
Thanks, AppArmor guys, for bypassing all the comfort of YaST so nicely. Otherwise, I maybe wouldn't have an opportunity to learn something new as I wouldn't have to write the above hack, necessary for correct translating of strings in YaST AppArmor UI. I'm just feeling a bit uneasy when I think about the fact that I (or somebody else) will have to maintain it all the way through SLE11 lifetime. Which is, 7 years.
- Mood:
bitchy
"An infinite number of mathematicians walks into a bar. The first one orders a beer. The second one orders half a beer. The third one orders quarter of a beer. It continues that way until the bartender interrupts and says: "You guys are all a bunch of idiots" and pours two beers."
Now I feel sort of weird if I find it so funny :-) (btw, it sound even more funny in czech/slovak). If you want to read more math and scientific jokes, one of my favourite non-fiction authors, Simon Singh, collects them. But I can't help myself, I find this one simply the best.
- Mood:
amused
Recently I had particularly excellent time with STL C++'s maps while fixing bug #439088 (a.k.a. "How to make hierarchical structure, which I cannot visualize, flat and keep the ordering of elements at the same time") ;-) :-D but that's not what I am going to write about. Now listen to the story of yast2-sudo:
Juggling with sudo rules
openSUSE 10.2 was the first release that came with user-friendly way of creating/editing sudo rules in YaST. If you ever wondered what are these for, they enable 'normal' (non-root) users to run specified commands as root (or other user), without actually knowing his password. The rules are stored in /etc/sudoers file and ... yes, right, the order really matters there. What does it mean? As the user invokes sudo, sudoers file is searched for matching rules. If multiple rules happen to match our user, the last one of those is taken into account. Which may not, unfortunately, be also the best one ;-)
Consider the following example: on your machine, you want to enable Tux the Penguin (user tux) to install additional cool software from openSUSE repositories by running YaST software (sw_single) module, but you don't want disclose root password to him. Easy as that, you will add a new rule to sudoers file that will enable Tux to run yast sw_single as the user in root group (and we won't ask him for password, too) as follows:
# don't try this at home, it will not do what you want :) tux ALL = (%root) NOPASSWD: /sbin/yast sw_single ALL ALL = (ALL) ALL
Now, will this really do the job? As mentioned above, out of multiple matching rules, the last one is applied. Tux matches the first rule, but also the second one, which will be unfortunately used in this case ('ALL' is a catch-all alias for any user - the rule basically says that everybody can do anything, but needs to enter the target user's password in order to do so). So this does not really help us. We want to do something like this:
# this is the right way ALL ALL = (ALL) ALL tux ALL = (%root) NOPASSWD: /sbin/yast sw_single
In other words, we want to place our rule to /etc/sudoers in such a way, that it will be the last matching one. And, last but not least, it would be also good if a configuration tool respected the order and didn't re-shuffle the rules whenever it sees fit, now wouldn't it?
Being an inexperienced greenhorn
yast2-sudo was the module that made me jump headlong into YaST development and, at the end, made a real YaSTie out of the shy girl I was before ;-) Writing it from scratch was the best way to understand how the components of YaST cooperate together (if you want to know more on this topic, here is some useful reading for you). However, it took almost two releases of openSUSE to discover the fundamental error I made in its design.
In YaST-speak, agent is the part of YaST module that grabs the configuration file, parses it and stuffs the data into some (more or less) reasonable data structure. As an inexperienced greenhorn, I wrote an agent in Perl that parses sudoers file. So far, so good. But as you might have already guessed, I used associative container (Perl hash, in this case) to hold sudoers data, not knowing that it will cause the rules to change their order, and mess everything up if the user is unlucky enough.
Cleaning up the mess
Now I had two options how to make yast2-sudo behave and preserve the order of sudo rules:
- Use Perl's tied hash in agent and make sure YCP preserves the order as well
- Store sudoers data in non-associative container and rewrite YCP stuff not to use maps, but lists
One more thing, though. I've added a small aid to user interface for you to help you prioritize your sudo rules:
- Mood:
drained
If you want to know more about Autoyast and how the cloning works, you'd better ask Uwe or read the official documentation maintained by him. This fairytale, liebe kinder, is about something slightly different.
In some cases, installing the whole system from scratch using Autoyast is not exactly what you have to (and want to) do. You might want to re-use only some well-defined bits and pieces of configuration that are proven to work on an old machine with a new one. And, of course, neither you want to browse the documentation, find the needed configuration files and copy-paste the lines there once again, nor you want to click through all the YaST modules for hundredth time over.
For example, you want to set up a shiny new workstation, with your home directory on local NFSv4 server with Kerberos authentication:
<nfs config:type="list">
<nfs_entry>
<mount_point>/home</mount_point>
<nfs_options>sec=krb5i,intr</nfs_options>
<server_path>nfs.myserver.net:/home</server_path>
<vfstype>nfs4</vfstype>
</nfs_entry>
</nfs>
Your company stores user identities in LDAP, so you'll need a working LDAP client as well:
<ldap>
<base_config_dn></base_config_dn>
<bind_dn></bind_dn>
<create_ldap config:type="boolean">false</create_ldap>
<file_server config:type="boolean">false</file_server>
<ldap_domain>ou=users,dc=myserver,dc=net</ldap_domain>
<ldap_server>ldap.myserver.net</ldap_server>
<ldap_tls config:type="boolean">false</ldap_tls>
<ldap_v2 config:type="boolean">false</ldap_v2>
<login_enabled config:type="boolean">true</login_enabled>
<member_attribute>member</member_attribute>
<pam_password>crypt</pam_password>
<start_autofs config:type="boolean">false</start_autofs>
<start_ldap config:type="boolean">true</start_ldap>
</ldap>
And, last but not least, you are behind a proxy and you want to set it up, too:
<proxy>
<enabled config:type="boolean">true</enabled>
<ftp_proxy>http://proxy.myserver.net:3128</ftp_proxy>
<http_proxy>http://proxy.myserver.net:3128</http_proxy>
<https_proxy>http://proxy.myserver.net:3128</https_proxy>
<no_proxy>localhost</no_proxy>
<proxy_password></proxy_password>
<proxy_user></proxy_user>
</proxy>
Now we gathered all the pieces of configuration we want to transfer to the new machine, so let's save it, e.g. in /var/lib/autoyast/repository/mycoolprofi
ayast_setup CLI in practice
ayast_setup is a commandline client designed exactly for the purpose of applying configuration stored in a small custom Autoyast XML profile to already running installed system. Let's see what it can do (some lines from the listing have been omitted for the sake of simplicity):
tux@pleczka:~> /sbin/yast ayast_setup help
YaST Configuration Module ayast_setup
--------------------------------------
Client for autoyast configuration on the running system
Basic Syntax:
yast2 ayast_setup interactive
yast2 ayast_setup <command> [verbose] [options]
....
yast2 ayast_setup <command> help
Commands:
setup Configure the system using given autoyast profile
We can see it supports only one possible command - setup. Let's have a look how to use it (just substitute 'setup' for <command> keyword above):
tux@pleczka:~> /sbin/yast ayast_setup setup help
YaST Configuration Module ayast_setup
--------------------------------------
Command 'setup'
Configure the system using given autoyast profile
Options:
filename [string] Path to autoyast profile
....
Options of the [string] type must be written in the form 'option=value'.
Example:
setup filename=/path/to/profile
We need to specify a path to profile as setup's command filename option. So let's do it:
tux@pleczka:~> /sbin/yast ayast_setup setup filename=/var/lib/autoinstallation/repository/mycoolprofile.xml
And we're done. Depending on the size of your custom Autoyast profile, you can now leave and have a coffee and/or something else while the system is being configured. It usually won't take more than one portion of the brain-stimulator of your choice :)
Some more notes
ayast_setup has been written by Uwe and polished by /me during HackWeek 3. Most of the time I use it for testing Autoyast-related bugs in my modules.
And for those not feeling comfortable in CLI, since openSUSE 11.1 also a clickety stuff can be used to do the same :) Just run 'yast autoyast', open the profile of your choice and then click on 'Apply to System'
- Mood:
distressed
When I used to maintain YaST ncurses frontend, I often heard people complaining how clumsy and hard to use it actually is. So I decided to do something against it, but at the same time I realized that people often do not use the full potential of user interface and many of kludges and gimmicks it offers simply remain hidden to them. This post is an attempt to broaden the education of those who live in console world only.
Hackers never read help
In the stone ages of openSUSE <= 11.0, on opening YaST window, there used to be a tiny little Press F1 for Help note in the top right corner. But ... have you ever seen a real hacker reading help? I haven't :-) Anyway, if you had opened the window, here is what you would have seen:
Quiz question: how to close the help window? :-)
If you were smart enough, you might have figured out that in order to create a new user in this dialog, instead of pressing eight (!) times Shift-Tab key to jump to the Add button, you could simply press F3 key and you were there. The thing is, however, that most users didn't figure out, kept pressing Shift-Tab relentlessly and complained afterwards.
So - how to show F-keys to the users and tell them how to use them, if they never bother to open help window? Yes, make them visible permanently! (I admit being strongly inspired by Midnight Commander). In openSUSE 11.0 a contrast bottom line listing available F-keys for current dialog appeared for the first time:
Lists, tables, trees, multi-selections & other beasts
These are basically UI elements (widgets) listing several items of one kind (e.g. all network cards in the system, RPM groups the packages can belong to, all system users and daemons,...). Using common sense, it is pretty easy to infer that up-arrow key moves the keyboard focus one item up, down-arrow key does the same in the downward direction, PageUp/PageDown key jumps one screen up/down, End key jumps to the last item (Home to the first one) and left-arrow and right-arrow scroll the pad horizontally.Ok, ok, this belongs to openSUSE I-am-newbie-and-I-am-totally-lost guide, but practice makes perfect :) There are however certain cool things that make tasks in UI easier and that are not obvious at the first sight
(Un)packing tree branches
Tree is an ideal widget to visualize something hierarchical - a nice example of that can be a directory structure. Take for example a sysconfig editor:
Besides jumping back and forth between the items, you need to pack or unpack tree branch to see what is hidden below (or to make the content of currently visible branch invisible again). Arrow keys have already different function (scrolling), so what to use here? SPACE key is not the only option to toggle branch state, you may press also Insert or '+' to unpack and Delete or '-' to pack the branch.
Sorting the tables
Tables in graphical UIs (Qt, Gtk) usually allow users to select a column that will be used as a key for sorting data in the table simply by clicking on that column. YaST ncurses UI enables you to do that, too. Don't you believe?Consider for example table, listing system groups. By default, they are sorted by name. But now I want to sort them by group ID. How do I do that? Well, simply by pressing Ctrl-O over the table and by selecting GID line in the small pop-up window that appears:
Quick multiselection
Multiselection box enables you to select more than one of several items. Like, in this example, you have one system group and you want to add several users to it:
Using SPACE or ENTER key to toggle user's group membership is an obvious choice. But if you want to select many users in a row, '+' key may come in handy. Not only it selects the user, it also jumps to the next one in the list, so you don't have to do it with arrow key yourself. '-' key works in pretty the same fashion for deselecting.
Don't peck 65536 times into up-arrow key
YaST uses so-called IntField widget for inserting integer values. Consider for example that you have 256 MB large swap partition and you want to double its size. That would mean ... gee, pressing up-arrow key 256 times! Fortunately, there is an easier way. Just press any number (0-9) over the number input field, enter the exact value into the small pop-up window that appears and you're done.
It is also helpful to see the minimum and maximum value of the number you can enter in the very same window.
And that's all, folks. ... and they used serial console with 80x25 linux term happily ever after :-)
- Mood:
sad
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif)
hedgehogpainter- Bubli
Syndicate
