However, after spending a day on it, I felt the need to get started with Linux. However, Vista isn’t that bad when you have a quad-core processor and 8 gigs of RAM. My problem is as follows:

• I need to be able to play games
• I want my games to run well
• I need a Linux environment
• Ideally, I’d run Linux natively

This leaves me with the obvious option of dual-booting, but I’d really rather not. I find it so… traumatic, if you will, to have to reboot my computer every time I want to change what I’m doing. And since I tend to fire up Team Fortress 2 rather frequently, I’m afraid I’d sit in Vista most of the time because of it, and only go to Linux when I need to. And that’s exactly the opposite of what I’d want. So what to do?

I don’t know what I’m going to do. In addition, while I’ve always had fun with Gentoo, the new installation I started has been proving challenging. The basic system was easy, but the framebuffered console and a desktop (with Compiz-Fusion) has proven difficult. This is in large part, I believe, because of the now-scattered documentation due to the data loss of our beloved Gentoo Wiki. And then I pop in an… an… Ubuntu (sorry, it just feels dirty to me) CD, and everything works. But it’s not quite right. It’s not perfect, and I don’t have portage, and I can’t use my shiny new computer to compile things all the time! (that was part of the reason I wanted such power ).

So I’m left with a dilemma. And because of my tendency to get paralyzed by indecision, I’ll probably stick with Vista for a while, until I figure out my solution, which will still probably involve dual-booting, since Wine doesn’t seem to be up to the task. If anyone’s got a similar situation/setup/solution, I’d love to hear about it. I love my Linux, but I also love my games.

1. mplayer’s tab-completion support does in fact come from bashcomp
2. this support is covered in the “base” module
3. the appropriate file uses strange regular expressions

At the time this bug was filed, the appropriate file to edit was (or was in) /etc/bash_completion. Since bash-completion-20081218, the bug was fixed, but the package also underwent some changes that seemingly caused locations of config files to change. (Apologies if this is incorrect, but I never went diving into the configs of bashcomp before now!)

In any case, the bashcomp configuration files are now in /usr/share/bash-completion. Since mplayer’s support is in base, the file that handles mplayer is “base” in that directory.

Now as for the “strange” regular expressions, that deserves some qualification. I’ve already seen lots of regular expressions on my (albeit rather short) day, but the reason I consider these ones strange is because they seem both unnecessary and redundant. The line in question is currently 5983 on my version 20081219-r1:

_filedir '@(mp?(e)g|MP?(E)G|wm[av]|WM[AV]|avi|AVI|asf|ASF|...|fl[iv]|FL[IV]...'

The two ellipses are my own adding, since the actual expression is one humongous line that ends up looking rather horrible here. My problems with this are both the explicit writing out of upper and lower case alternatives and the the bothering to do things like fl[iv]. Actually, I don’t have a problem with the latter except in the presence of the former. And to be fair, I probably wouldn’t have ever cared or noticed if I hadn’t been able to find “flv” when grepping numerous files. Not that “greppability” is necessarily a goal for configuration files, but it’s certainly annoying when it’s specifically hindered by regular expressions that save negligible space like the ones in this file.

As a final note, I’m going to disclaim that I’m no expert on bash scripting and the various intricacies of handling regular expressions therein, so I’d be happy to hear from anyone who knows better about why I should lay off the poor bash-completion folks.

External Links

• Gentoo Bugzilla bug on mplayer tab-completion
• Previous post on mplayer’s tab-completion

I’m not quite sure how the tab-completion infrastructure works, but I know it’s got a lot of “packages” for different programs. A surprising amount, actually. For the uninitiated, on my system, I’m looking at:

dfego@antica ~ $ eselect bashcomp list
Available completions:
[1] _subversion
[2] apache2ctl
[3] base *
[4] bitkeeper
[5] bittorrent
[6] cksfv
[7] clisp
[8] dsniff
[9] eselect *
[10] freeciv
[11] gcl
[12] gentoo *
[13] git *
[14] gkrellm
[15] gnatmake
[16] gpg2
[17] gvim
[18] harbour
[19] isql
[20] larch
[21] lilypond
[22] lisp
[23] mailman
[24] mcrypt
[25] mercurial *
[26] modules
[27] monodevelop
[28] mpc *
[29] mtx
[30] p4
[31] povray
[32] qdbus
[33] ri
[34] sbcl
[35] sitecopy
[36] snownews
[37] ssh *
[38] subversion *
[39] tig *
[40] tree *
[41] unace
[42] unrar *
[43] vim *
[44] xxd

The ones with the asterisks are ones I currently have enabled for my main user. As you can see, there are a lot of options to choose from, and for some weird reason, my git functionality died after a recent update. But wait… mplayer isn’t there… Interesting…

Interesting…

So where does mplayer’s tab-completion come from? It’s not just the normal one provided by the shell, because it before excluded certain file types.

Interesting. This must be investigated.

Cannot create link /etc/mtab
perhaps there is a stale lockfile?

Naturally thinking it was my project’s fault (it was), I rebooted into my normal kernel. To my horror, the same error came up. After a period of mini-panic, I ran to Google and at the same time reached for my Gentoo CD (the newest I could find was 2007.0 minimal, but it still works!). I ran e2fsck on both my home and root partitions for good measure, and then mounted my root partition and looked at /etc/mtab*. Apparently, the fact that there was mtab, mtab~, mtab~2205 and mtab~2213 isn’t normal. On recommendation from this obscure post from three years ago, I deleted the extra files (after examining them and noting they were not only extraneous but empty), rebooted, and viola! Problem solved!

Turns out a number of different things I did caused this error several different times. Not exactly sure why, but it always seems to coincide with the boot of or boot after a kernel oops or panic.

External Links

• Obscure post from 2006

On Saturday, myself and 7 of my classmates from GWU had a chance to head up to Lancaster, PA to the home of White Wolf Security for the 4th Annual Mid-Atlantic Collegiate Cyber Defense Competition Qualifying Round. At this round of the competition along with GWU were George Mason, Jameson Madison, and Millersville Universities. For those who aren’t familiar, the competition puts the students in the roles of system administrators who were recently hired to secure and maintain a company’s network. The whole affair is pretty exciting, and the pressure can get very intense. While attempting to prevent and root out attacks from an all-volunteer (but skilled) red team sitting in another room, a white team also throws business injects at us that have us do things like install wikis, set up PKI, and create office templates for our company. We get scored separately on attack prevention, injects, and service uptime, and at the end of the day the top two teams move on to the next round. The whole competition ran for about 7 hours, and we were getting pounded from minute 1.

The Plan

After experiencing the chaos last year, we put together a list of basic things to do as soon as everything started that would keep out the easiest attacks. After blocking all external traffic with our firewall (for a few minutes so we could have some “safe time”), we set out to do these things in the first 15 minutes or so. This was just changing all the passwords on the boxes, killing extraneous services, setting client firewalls, and backing up important data and configuration files. I only managed to get to changing passwords on the boxes I was handling. They gave us 4 Linux boxes, and those were the ones I was in charge of. They weren’t the newest versions of the OS’s, and for the life of me I can’t understand how our Nagios box (Fedora, I believe) didn’t come with lsof, but I did my best to get everything locked down.

The First Problem

Well, the best plans of mice and men blah blah blah, and in the few minutes it took our firewall guy to figure out where the admin console was, the red had team managed to get onto two of the Linux boxes and leave their mark before I had a chance to change the root passwords. After about an hour, I noticed the intrusion on one of the boxes as I attempted to set up iptables and noticed that there were a bunch of identical ACCEPT rules in there that I didn’t put there. It was go time.

The Source

I called over our team captain to let him know there was a problem, and I set out to figure out just what was going on. I flushed the tables, set the firewall policies to DROP, and hopped over to /sbin to take a look if anything seemed weird. After checking iptables again, I noticed some more ACCEPT rules were in there. I cleared them out and opened the crontab to see if anything was running; it wasn’t. Not sure what was going on, I took a moment to restart SSH to boot off any active connections, just in case. Upon examining the files in /sbin, there were some that were world-writable. I knew that wasn’t quite right. One of those files, however, was iptables. At cappy’s suggestion, I viewed the contents of the file, and sure enough it was a perl script instead of the iptables binary. Since I was under the gun I didn’t quite deduce what the script did, but it called the real iptables (which they renamed) with ACCEPT commands, instead of the ones I kept giving it. While the real iptables was mentioned in that perl script, I didn’t quite catch on right away, so I looked at the size of iptables on another computer and looked for a binary in /sbin with a similar size, and found it. After that, I chmod-ed all the files in /sbin to remove world-writability, to prevent any further problems in case of non-root intrusion.

The Solution

At this point, I had found intruder access, a malicious script, and a moved iptables. However, more and more ACCEPTs kept being added to my chains. Once again at cappy’s suggestion, I moved the real iptables to another name, and left their script in place as “evidence,” and in case they had any mechanism for replacing it. This seemed to finally stop the problem. At this point, I just needed to figure out where our attackers came from. The rules of the competition say we can’t completely block any IP addresses without approval from the white team, which will come if we have details proving that the IP is malicious. I believe the reasoning for this is so that we can’t just block any IP range, as well as the fact that the scoring bot shifts IPs, so we could also screw ourselves if we just blocked lots of them.

The Culprit

I needed to find out the intruder, but I didn’t know how. I took a look in /var/log and saw a bunch of files, more than I usually see, so apparently I don’t log enough on my own computer. My first look was at /var/log/messages, but that didn’t yield anything of value. Next, I stumbled across /var/log/secure, which seemed to be a log of SSH activity. I hit the jackpot, because I found logins about an hour and a half prior by two specific IP addresses. I was ecstatic. This was our culprit. I was surprised that they didn’t delete such logs, but perhaps they didn’t think of it, or were instructed not to by the white team, as not to make our jobs of tracking them impossible. In any case, I saved the log to a file, filled out an incident report, and sent it over to the white team. They looked over the report and checked on something (I honestly don’t know what) and then let us block the IPs. Mission accomplished.

The Wikis

Well, at least that mission was accomplished. I felt pretty good a little after 11am when this all was wrapped up, but that quickly faded as business injects got annoying. We had to install wiki software, which gave us infinite problems. We first tried MediaWiki, which was a bust because our database server was using MySQL 3.x. 3.x? What the hell? I’ve never seen that anywhere before. My impeccable sources tell me that it’s about 9 years old! Yeah, pretty egregious, but there wasn’t too much we could do about it under the circumstances. So we looked for other softwares, of which there were many. However, after failing to find Tigerwiki (apparently it’s discontinued) and having ridiculous troubles with MoinMoin and TikiWiki, we ended up running out of time and failing the inject. That wouldn’t have been so bad if it weren’t for having another inject which built off of that one later in the day. So that sucked. In the end, we found an older version of MediaWiki (why didn’t we think of it earlier?) and installed that for the second inject, but we ran out of time and failed. And in that last bit when I say “we,” I mean two of my teammates, because I was sick of wikis and had to step away before bashing the computer with a chair.

The Cable

The rest of the day was relatively less pressure for me, just keeping a check on my systems, handling another inject, and trying to get our damn Nagios box to actually work. For some reason, it wasn’t connected to anything. We couldn’t explain it, though we thought our routes were a bit screwy. After a lot of investigation, one of my teammates brilliantly found that there was no network cable in the computer. I know, I know, that’s normally the first thing to check, but we were given computers and were allowed to assume that there’d at least be cables in everything! And it’s not like it had come loose or fallen out or anything; there was just no cable for that box. So we went to the white team and they remedied the problem, but we all had a good laugh over that. In the afternoon there was also another intrusion that I helped get logs for, but it wasn’t nearly as exciting as the morning breach.

The Nagios Box

Amidst everything else I was doing, I took a good shot in the afternoon to configure our Nagios box. I remembered from the last competition that the IPs were wrong, so that seemed to be what I’d probably have to do again, just fix up the network portion to that which we were assigned for all the entries. Simple enough with sed. However, I found enormous difficulties getting into the web console, considering they didn’t give us the username and password, and they weren’t any kind of defaults. Well, in the end, it turns out they were. “nagiosadmin” is apparently a standard username, and the password was the standard one for the competition. It just took way too long to figure that out. Once I fixed the IPs and logged in, I realized that all most of the checks were failing. Not good. That generally meant that the scorebot also would be counting those tests as failures. I talked to our firewall guy, who had egress filtering on (blocking outgoing traffic), which he suggested would give such results. We argued, he got busy, and I never got to see the beautiful green colors of Nagios that come with a fully working network. Oh well. At around 4, the competition ended, we packed up our computers, and we headed over to another room for a debrief.

The End

All tired, hungry, and anxious to hear the results, we waited and were fed pizza while the event organizers talked to us for a while. Then they let the red team have a go and both tell us what they did to us over the day, as well as query us about our strategies and give us some tips for defending. I actually got to talk to the guy who put that perl script on the Linux boxes, and he asked “did you find the others?” We laughed, and then realized that we hadn’t even looked for others. It didn’t even occur to us for some reason. So he pointed out that if you find something malicious, there’s almost certainly something else there, and you should make some effort to find it. He suggested grepping all the files in /sbin for “perl”, while I probably would have used “find” to find any files modified in the last few hours. Either way, it’s something solid that I learned and will most certainly apply at the next competition. Which leads to the most awesome part: GWU got 2nd place, and we’ll be competing at the regionals in Baltimore in March! We’ve got a lot of work to do, myself included.

All in all, I found the whole thing very worthwhile for the third time, and recommend any college students in the US with an interest in computer security to look at creating a team and competing in a regional competition. The whole affair, while stressful, is not only fun but a great experience for anyone interested in information assurance. As a matter of fact, I’m not particularly enthralled with security and I found it a great experience too. In past events (but not this one, because of the inauguration), we had Secret Service agents there as well to talk to us a bit and have to consult regarding some of the legal issues with intrusions, to discuss our incident reports with, and have drinks with afterward. I can’t wait until March. Maybe we’ll make nationals!

External Links

• White Wolf Security
• Mid-Atlantic CCDC Information
• National CCDC Website
• Nagios Website

As it turns out, after the first 8 characters, I could have put in anything at all, and the login would work. I was shocked that such a strange security issue would come up on a mostly stock-configured Ubuntu 8.04 server. In fact, it was better than stock configured, as I already had to do a bunch of configurations to secure it.

As it turns out, the problem lied with the way PAM was authenticating (or something). I went and checked that my configurations were right (you should have “md5″ in a “password” line where commented to do so in /etc/pam.d/common-password). Then, after doing some more poking around online, I found an Ubuntu forum post that mentioned that in /etc/shadow, if any given password has $1$ at the beginning, it’s using MD5. Upon looking at my shadow file, it turned out that one of my users (the one with the issue) was somehow not using MD5. I don’t quite know how that happened, but I’m going to guess that I configured PAM for MD5 after last setting his password. At least that’s my best guess.

To fix the issue, I just used passwd to change the password for the given user, and it properly took on its MD5 encryption. I hope this proves useful to someone in the future!

It’s actually rather ingenious if you think about it, and there are plenty of references that give great explanations of how it all works, so I won’t do that here. The short version is that the list actually acts like an element within another data structure, which allows it to work for all types, rather than having to create new structures and functions for every structure to act like a list. What I recently found myself trying to do was create a queue (first-in-first-out) data structure using the linked lists provided. I decided to go about this after getting a little advice from a couple of fellas over at Stack Overflow. I haven’t fleshed it all out yet, but came to an important realization on how things work. It’s not really all that hard, but it was important enough for me to want to document: because it is a circular, doubly-linked structure, adding an item to the front and back of the list look very similar. In fact, they’re pretty much the same operation, except for where the external head and tail pointers point to. They’re so similar that I spent a bunch of time confused on how it all worked. I suppose that’s my fault for delving in and examining the overly-short elegant code.

The result of this is that their list_add_tail() function (which is commented to be useful for queues) is, in fact, useful for queues. It adds an element linked after the “last” element and before the “first,” given the head of the list. “Last” and “first” are in quotes here because it’s a circular list, so there technically aren’t a first and last, but there are. Anyway, what I still don’t quite understand is how the list_add() function is useful for stacks (also in the comments). Though I’m getting myself slightly confused just thinking about it further, so I’ll end the tirade here.

I guess if there’s one thing I can pass on here, it’s that if there’s comments documenting a series of functions (which the kernel’s include/linux/list.h file does), listen to the comments. I suppose this was a learning experience for me in the end, but I could have saved a bunch of time by just trusting what they said the functions do. On the flip side, if you’re curious, don’t trust them, and want to be sure about what the code is doing, you are always free to dive right in! I’m just convinced that the kernel developers are a lot smarter than I am, at least at this point in my career.

Related Links

• Linux Kernel Linked List Explained
• Another Kernel Linked List Explanation
• Stack Overflow question about kernel queues
• list.h on Linux Cross Reference

• All my music (even the music I don’t listen to, so I don’t have to get rid of it)
• The music I listen to on my computer
• The music I have on my limited-space iPod

In addition, I wanted to make sure there was as little wasted disk space as possible, so I used hard links and had all the files in separate directories.

You’d think there would be a relatively simple solution, and I’d hope so too, but I came up with this really convoluted system that involved synchronizing three directories with two scripts whenever music had to be added or removed. What it results in is that I never add music anymore. And somewhere along the line, my “music on my computer” folder got messed up, so I’m back to square-one with that one. Hundreds of songs I filtered out back in the mix.

I wonder if some of my problems would be solved if I used a GUI music player, but I’m not so sure. My current setup uses MPD, which runs nice and light. Anyway, I’m out of mental energy, and am hoping someone else might have a better idea. Does anyone have any good ideas how to maintain my music? Or perhaps a better ideal to work under? Until then, I’ll just suffer under a horrible manual version where I just delete and add things at will to everything and hope I don’t miss things.

Commonalities and Usage

First things first, equery and q are both very similar both in offered functionality and usage from the command line. Basic usage goes like so:

$ equery [command] [package]
or
$ q [command] [package]

Simple, right? There are also options to modify usage, but this is the most basic and common usage pattern.

In terms of functionality, equery and q have the following in common:

The usage of each of the above commands is pretty straightforward, so I won’t bore you with details. Running just “equery” or “q” from the command line will show all basic usage, and running one of the above commands without arguments (or with a -h local argument, for equery) will show similar usage info for the specific command.

equery

equery is a part of the gentoolkit package, is written in Python, and is rather well-endowed (in terms of features, of course). In terms of features unique from q, equery boasts:

• depgraph: display a dependency tree for a given package
• uses: display USE flags for a given package
• which: print full path to ebuild for a given package

Personally, of these three, I’ve only ever used uses, since I the few times I’ve ever attempted to use depgraph, the results have been too big to really get a handle on. Either way, the uses command makes it a lot easier to find out what USE flags are available for a particular package as well as their current states. Of course, you could just do a (not so quick):

$ emerge -pv [package]

However, that won’t give the information on what the USE flags actually are, just what their status is on the package.

equery in general gives more detail and nicer output than its shorter-named counterpart. Since I always like to see screen shots (yes, even from command-line programs), I’ll take the liberty of doing just that to illustrate my point:

Output of equery list zsnes command.

Output of qsearch zsnes command.

One thing to note about this particular command is that while qsearch automatically searches both installed packages and those in the portage tree, equery requires the -p option, as shown above, to do the same thing. On the flip side, qsearch has no capability (at this time) of searching overlays, but equery can be made to do so with the -o option. Tradeoffs, tradeoffs!

As a final note on equery, there are in fact two ways to call each of the sub-programs (like list, depgraph, etc.). There’s a short and long option for each of them, which is rather convenient. “equery l” is much nicer than “equery list” and “equery g” is way better than “equery depgraph.”

q

On to q! After reading the above section, you might wonder why anyone would want to use q when they’ve got equery in their toolbox. Is it for those few features that q has that are so dazzling? Is it because the name is shorter? No, no, let me just show you, you’ll understand:

Timed output of equery list zsnes.

Timed output of qsearch zsnes.

For those of you who can’t see the images or are just in plain shock, let me spell it out: q is fast. In that particular query, about 34 times faster. 34 times faster! That makes a big difference, whether you’re sitting in front of the keyboard twiddling your thumbs or putting it in a shell script. As a matter of fact, on running just the q or equery commands alone (to show the helpful usage messages), the speed difference is over 500 times! That being said, if you don’t need the fancy formatting and extra frills of equery for a given task, just use q. It’s faster. According to its Gentoo page, that’s its purpose anyway:

portage-utils is a collection of very fast utilities written in C, which are meant to offer a faster but more limited alternative to their gentoolkit counterparts. Please note that portage-utils is not meant to replace gentoolkit. Its utilities are much more efficient than the equivalent ones from gentoolkit and might be better suited to be used in scripts that need to call Portage repeatedly, but portage-utils does not offer the same functionalities.

Well hot-damn, I could have told you that from the beginning, no? It’s times like this that I sing the praises of C and mock all those Python people. Then I try to write a difficult program and cry myself to sleep.

Anyway, language wars and tearful nights aside, there are also a couple of other distinguishing things about q. First, its simple format can make parsing a bit simpler. Then again, it could make it harder, so let’s not go there. As a matter of fact, equery makes a point of modifying its output if you redirect its output. If you don’t like the modified style of output, you can pass the -N (–no-pipe) flag to turn that behavior off.

Second, q does bring a few unique functions to the table. Namely:

• atom: split up an atom string (like games-emulation/zsnes-1.51-r2 -> games-emulation zsnes 1.51 r2)
• cache: search the metadata cache
• grep: grep in ebuilds
• lop: emerge log analyzer
• merge, pkg, tbz2, xpak: all pertain to actually handling various types of packages, which I have no experience with, so I don’t know their usage.

The one that I find particularly is “lop.” In an example from that Gentoo page on portage-utils, try something like:

$ qlop -tH openoffice

It’ll tell you “the merge time” for that package. Now, I’m not sure if that means the last merge or some sort of aggregate. My output tells me:

openoffice: 9 hours, 19 minutes, 11 seconds for 12 merges

I’m guessing that means that it took 9:19:11 to merge 12 packages, in terms of the package in question and its dependencies, but I’m not totally sure on that one. Either way, this is a damn nifty feature. I make jokes all the time about how long some packages take to emerge, and how I can have actual times to back me up! Oh the joys of Gentoo…

As another very useful note, the qsearch command is also substantially faster than “emerge –search.” It’s not nearly as impressive as it is against equery, but it holds its own. An advantage that qsearch has over its equery counterpart, however, is that it has the ability (and has it default) of displaying descriptions of packages. I actually for a long time forgot how to do that on my system, and always ran to gentoo-portage.com.

Last but not least, just like equery, q commands can be shortened as well. Unfortunately, that just means changing something like “q search” to “qsearch.” Not a big improvement, but with a one-letter command, how much can you really ask for?

Why both?

In brief, the snippet above from the Gentoo article on portage-utils gives the answer quite nicely. q may be lacking, but it can be an order of magnitude faster than equery. For those times when you don’t need all that fancy-shmancy formatting and just want to get quick and dirty results, q is your tool.

Anyway, this all correlates to a recent issue I’ve had with my music accounting system, and how I got around it with some frenzied bash scripting. Because I’ve got a 4GB iPod Nano, I eventually came into the position of having too much music to fit on the device. So I looked at my music and thought about compression. Unfortunately, I couldn’t glean nearly enough space from that. Then I realized that I have way more music than I actually listen to, so why not keep some music for computer listening, and some for mobile? Well that’s a fantastic idea, but implementation gets a bit sticky. I can try some convoluted system in which I keep a file of the unwanted files, update that manually, and… yeah, not too pretty. Although I can’t quite say my solution was much prettier.

My current system involves a ~/music directory, and a ~/music-all directory. My intention is to delete nothing from ~/music-all, ever. ~/music contains music I actually want to listen to, and ~/music-ipod will contain music that I like enough to carry in my 4GB of space. The key is that all the files within these three directories are hard links, so I’m not actually increasing my disk usage very much, and operations on the sets of files are much faster than if I had more than one copy of my files. So assuming I hard link everything in ~/music-all to ~/music, I can then delete things from music at will, without losing it from my drive, but getting rid of it from listening.

With a schema in mind, then there’s the question of how to keep it up to date. There are times when I want to add music to my collection, but then what do I do? I could manually link the new files over, but… well, in retrospect, perhaps that would have been simpler. But I decided I needed a script which would note the differences, relink ~/music-all to ~/music, then remove the files that I noted earlier (which were saved in a text file). The benefit of all my toil was that it now makes my updates lightning fast and not tedious in the least. I had to come up with two scripts, however: one to be run prior to changes to ~/music-all, and one once they’re made. Below are the scripts, which probably won’t be of much use to anyone else, but they can essentially be used to keep two directories in sync, but with certain persistent changes.

mtree-1
mtree-2

Wow, I just spent way too much time figuring out how to post code here, and I’m still not satisfied with the result, so I ditched it. The built-in <code> tag doesn’t seem to take to multiple lines all that well… If anyone knows how to do that, do let me know!