Oops. I changed the pcmcia-cs network script so that it no longer sources network.opts, which can be used to define schemes.
I think we should stick with the standard network.options configuration. The /etc/conf.d/net stuff works but as you've stated it breaks schemes. People expect to see scheme support.
What's up with this bug?
Well, I talked with Azarah at one time about getting Gentoo schemes working (it will require some tweaks to the init scripts). One thing we can think about is incorporating quickswitch more closely. I use it and it works really nicely. The only problem is it gets us away from Gentoo's /etc/conf.d/net setup. Ideally, we need that config file to be more like quickswitch's config file, but once again that requires some init script hacking.
Before this thing dies, let me repeat my answer to Chad. Please have a look how you guys want things to work, preferribly without hacking things to pieces, and then get back to me on how you want net.eth0 or whatever changed, or at least how you would like it to behave.
Is this issue being worked on? I would very much like the 'scheme' scheme working out of the box.
bah. i shoulda looked here first. what i thought, script customizations kill cardctl scheme. looks like i too would also prefer cardctl scheme working too. Since a pcmcia wireless card has the ability to browse several networks, would be nice to be able to use a scheme for the setup instead of hacking the config files daily (<-- if one goes to work daily with a laptop and then returns home...me, i do use starbuck's tmobile every now and then ;-) in the mean time, i'll hunt down quickswitches config file. btw, there's no other real help on this bug/issue with distro's modifying the scripts to break this feature of cardctl (except some mention on redhat breaking theirs).
ok. gave quickswitch a try. it works. i revied the sample config file and it looks a bit messy. had to comment 3/4's of the stuff out. This might be a bit OT, but isn't there a way to connect to a specific AP instead of the wireless network card just guessing? ie, two access points with their names set to "default" and the wireless card will connect to the first one. isn't there a way to specify to use an AP that has "MAC Address" && "Essid"?
here's my follow-up to experimenting with quickswitch. Although quickswitch does work, it makes a complete mess out of init.d scripts. Ie. when i stop net.eth1, it also goes through stops 10 other services (sshd, apache, which isn't good if you have several nic cards installed for one.) A couple of options would be to augment quickswitch to work with gentoo (the end result will probably be messy). Or, to include pcmcia schemes to work with gentoo. The later seems more reasonable. (another thought comes to mind, maybe implementing a custom script -- like quickswitch -- but only focused to handling diff pcmcia schemes. well, i've already done a 'emerge -C quickswitch' -- it made switching nic schemes more complicated (lol...yup. it i did) and it made a mess of init.d scripts.
I don't know jack about quickswitch but here is my simple hack to get good old pcmcia-cs schemes working. First, I added this line to /etc/pcmcia/network: export ADDRESS right under the line that sets it. Then I modified /etc/conf.d/net. It now has access to $ADDRESS. So, following /etc/pcmcia/network.opts, I wrapped my configs in a case "$ADDRESS" in home,*,*,*) iface_eth0=... ;; *,*,*,*) dhcpcd_eth0=... ;; esac This way the Gentoo network config is still done in /etc/conf.d. Pretty simple, eh? Add one line to /etc/pcmcia/network and a few (initially commented-out) case lines with a note saying "If you are using pcmcia schemes uncomment the case lines and you can switch on $ADDRESS just like /etc/pcmcia/network.opts." Even if my suggestion is not used, I recommend changing /etc/pcmcia/network.opts to have a big note at the beginning: *** THIS FILE IS NOT USED IN GENTOO *** Configuration is done in /etc/conf.d/net{.$DEVICE}
ditto. i have yet to try this. messed enough with quickswitch which ate up about 2-3 weeks of my time..including the time to resorting to the original gentoo files after I figured out my original setup was just as easy as using quickswitch! eh, I simiply utilize the /etc/init.d/net.* files and utilze a second script to attach the wireless net.eth1 to my wap and then will manually edit the script to do dhcp when i need it too. :-(
Well, I just got a new laptop with built-in ethernet and wireless devices so that cardmgr, and hence its schemes system, never touches them. So, I installed quickswitch and got it working. Nothing against the program itself, but it does not integrate into Gentoo at all. I think we need a general scheme system for Gentoo with the following features: - it should dovetail into pcmcia-cs - it should use the Gentoo config infrastructure: - rc script dependencies - config in /etc/conf.d - it shouldn't require overhaul of all the other Gentoo stuff to get it to work What I'm going to tinker with is creating a master scheme rc script that will manage scheming. It will get its config from /etc/conf.d. Other rc scripts will depend on it. To change the scheme, one will run "scheme-update <foo>" which will change the scheme recorded in /etc/conf.d and restart /etc/init.d/scheme, which, through dependencies, will stop/start other rc scripts that setup network devices, set hostname, change dns, etc. /etc/init.d/scheme will not be monolithic like quickswitch. Who knows what does and doesn't need to change with scheme changes? Quickswitch assumed a network config change but that didn't apply to me. I'm going to create a few additional rc scripts that are scheme-aware to manage things like munging the /etc/hosts file. For compatibility, /etc/init.d/scheme will do symlink changing so that all of the rc scripts don't need to become scheme-aware immediately. For example, /etc/init.d/net.eth0 can stay scheme ignorant. /etc/init.d/scheme will just make a symlink from /etc/conf.d/net to /etc/conf.d/net.<foo> so that the new config will be set when /etc/init.d/net.eth0 is restarted. I haven't figured out how to handle the fact that you may not want to restart a rc script but rather just stop it or that there may be new rc scripts you want to start. This problem makes me think that schemes are like runlevels with per-runlevel config but I've had too much coffee and I'm starting to ramble. Comments appreciated.
I like the approach outlined above with exporting ADDRESS from pcmcia scripts; I would modify the pcmcia script to export only the scheme, perhaps, and then wrap the Gentoo conf.d/net.{interface} scripts with SCHEME cases. Whatever we do, we MUST IMPROVE THE CURRENT SYSTEM, WHICH SUCKS. The pcmcia-cs config scripts are way too convoluted; they stomp on one another. I cannot predict from one boot to the next which scheme my wireless card will pick up. I've attempted to modify the pcmcia-cs scripts and the init.d/pcmica script to lobotomize them -- to remove files in /var/run, to simplify things -- and I have come to believe that the best thing to do is to use the pcmcia-cs initialization as little as possible.
Okay, here is my scheme hack. The fundamental idea is: schemes are runlevels. Now, I did not hack init to change the possible runlevels. Rather, /etc/runlevels/default becomes a symbolic link that points to the current scheme/runlevel. First, I've created an RC script /etc/init.d/rc.scheme (attached). It has two purposes. (1) It changes the symlink /etc/runlevels/default to a new scheme if need be. This will happen when start()ing if the environment var NEW_SCHEME or the kernel boot parameter BOOT_SCHEME does not equal the current scheme. When stop()ing this will happen if the scheme config file /etc/conf.d/scheme sets the variable "shutdown" and it isn't the current scheme. So far pretty simple, eh? This rc script needs to run before any scheme-dependent rc-scripts are run. I put it early in the boot runlevel. Now, how do rc-scripts know the current scheme? I've defined a shell function called current_scheme() that basically calls readlink on /etc/runlevels/default (attached). It should go in /sbin/functions.sh but I put it in /etc/conf.d/rc for the time being so it doesn't go away when I update. Any rc-script can switch on `current_scheme` (see attached example). (2) What about those things that do not use /etc/conf.d? This is where the second purpose of the scheme rc-script comes into play. In /etc/conf.d/scheme there is a varible "schemed_files". In addition to symlinking /etc/runlevel/default as needed, for each $file in $schemed_files it symlinks $file to $file.scheme (if it exists). For example, I have schemes dhcp-wired, dhcp-wireless, and nonet. It symlinks /etc/ntp.conf to /etc/ntp.conf.dhcp-wired or /etc/ntp.conf.dhcp-wireless. So, this handles scheming during booting. What about scheme changes after booting? For this, I have created a script "scheme" (attached) that will change schemes (the new scheme is given as an argument). What does it do? Simple: it exports the variable NEW_SCHEME and calls /sbin/rc "${NEW_SCHEME}". Services are stopped and started as needed by rc. There is one wrinkle: what if a service is in the current scheme and the new scheme? /sbin/rc won't restart it. The scheme script manually stops these services. Then rc will start them again. Some services do not need to be restarted on scheme change so I created a variable "restart" in /etc/conf.d/scheme that lists the rc-scripts that should be restarted on scheme change. Starting and stopping may not be the right thing to do. Some scripts may want to know that the scheme has changed. To accomplish this I created a new command to the rc-scripts called "schemechange." Those rc-scripts listed in the varible "schemechange" in /etc/conf.d/scheme will be invoked with the argument "schemechange" (as opposed to "stop" or "start"). I have been using this for a couple months with little problems, though my situation may be simple. However, there is one important piece missing: integration into pcmcia-cs. I haven't done this because I got a new laptop that has everything built in so I don't even use pcmcia-cs anymore. Nevertheless I beleive it is possible to show pcmcia-cs the way. Possibly changing the get_info() function in /etc/pcmcia/shared is suffcient. That way, when you insert a card, instead of /etc/pcmcia/shared setting the scheme with SCHEME=`cat /var/lib/pcmcia/scheme` or SCHEME=`cat /var/run/pcmcia-scheme` it does SCHEME=`current_scheme.` It would be simple to create an rc-script that calls "cardctl scheme ${NEW_SCHEME}" so that changing the Gentoo scheme would cause the pcmcia-cs scheme to change too, keeping them in sync. One should never call "cardctl scheme <scheme>" directly then.
Created attachment 17621 [details] rc-script for scheming
Created attachment 17622 [details] current_scheme() function Defines current_scheme() and scheme_exists(). Should go in /sbin/functions.sh maybe.
Created attachment 17623 [details] Sample schemed /etc/conf.d/net
Created attachment 17624 [details] Script to change schemes.
Hi is there still work done on scheme support? What is the conclusion? I would like to get it working in a standard way without any hacks. thanks, fabian p.s. if there is something new which should replace the current way gentoo uses schemes but is still in development I would be happy to help testing
It has been months without activity on this bug . . . still I cannot issue the command "cardctl scheme name" like all the instructions everywhere else say to do . . . I really dislike having to hand edit config files and restarting pcmcia every time I go to work or school. What is the status here?
this is funny. after a pcmcia-cs update on this box (about a month or two ago), pcmcia schemes now work. I can simply plug in my card (in & out) with the wireless pcmcia card and it "just works". However, after doing a clean install on another hard drive and then simply copying over all the /etc/pcmcia & /etc/config.d/pcmcia files, pcmcia schemes still does not work on that freshly installed o/s. Is there another file someplace that can break pcmcia schemes? stumped, would like to switch on --verbose printing on the scripts to find out which files are getting processed during the insert of the pcmcia wireless card. I doubt that I also forgot to copy over the /etc/init.d/pcmcia file, but will double check.
I saw one of the conversations listed in the GWN about net-card configuration. This seems to be a dependancy for that type thing.. and oh do I ever want to just be able to plug things in and have them work. it looks like this is tied in with hotplug?
The last time I checked (i.e. when I last modified the ebuild) -- and I think this is still the case -- the only thing preventing pcmcia-cs from working normally is the fact that the /etc/pcmcia/network script has been modified. Just grab a pristine copy of that file from the pcmcia-cs tarball and drop it in /etc/pcmcia, and all should be well. I thought I had stuck a copy in /usr/portage/sys-apps/pcmcia-cs/files, but it isn't there now.
mmm... Like i said, i've got the entire folders /etc/pcmcia & /etc/config/pcmcia copied over to the new system, yet the wireless pcmcia card doesn't automagically hook-up. yet on this box, it did/does (right after I upgraded pcmcia to the current release a month or two ago).. I was like "yowza! ... It's works!" ;-) ... but it don't now on my new freshly installed gentoo box. only files that differ are /etc/init.d/pcmcia -- i think.
Is there any reason why the title of this bug has been changed? pcmcia-cs schemes aren't just used for networking.
We support PCMCIA schemes for anything non-network related already.
GAH! Where's the plain vanilla pcmcia-cs when you need it?!? I'm able to handle the default schemes and whatnot eazily, and was planning on writing a scheme handler. Now in order to do that on a Gentoo laptop, I have to MANUALLY compile pcmcia-cs. I might as well start the local Portage here and create vanilla-pcmcia-cs....
The newly added sys-apps/pcmcia-cs-3.2.8-r1 will use the original network script when emerged with USE="vanilla", thus allowing people to use PCMCIA schemes etc.
